Prepositioning Empty Vehicles Based on Predicted Future Demand

ABSTRACT

An automated ridesharing dispatch system includes a memory configured to store historical data associated with past demand for ridesharing vehicles in a geographical area and a communications interface. The system also includes at least one processor configured to access the memory and to use the historical data to predict imminent demand of ridesharing requests including predicting general zones in the geographical area associated with imminent demand, select a holding zone for prepositioning empty ridesharing vehicles in order to expedite satisfaction of the predicted imminent demand, and send, via the communications interface, to a mobile communications device in a specific ridesharing vehicle, instructions directing the specific ridesharing vehicle to the holding zone.

CROSS REFERENCES TO RELATED APPLICATIONS

This application claims the benefit of priority of U.S. ProvisionalPatent Application No. 62/450,239, filed Jan. 25, 2017; U.S. ProvisionalPatent Application No. 62/500,109, filed May 2, 2017; and U.S.Provisional Patent Application No. 62/537,155, filed Jul. 26, 2017. Allof the foregoing applications are incorporated herein by reference intheir entirety.

BACKGROUND I. Technical Field

The present disclosure generally relates to the field of vehicleridesharing and systems and methods for ridesharing management.

II. Background Information

Recent years have witnessed increasing interest and development in thefield of vehicle sharing, where one or more riders may share the samevehicle for a portion of their rides. Ridesharing may save ride costs,increase vehicle utilization, and reduce air pollution. A rider may usea ridesharing service through a ridesharing service application accessedby the rider's mobile device.

SUMMARY

Embodiments consistent with the present disclosure provide systems andmethods for vehicle ridesharing and for managing a fleet of ridesharingvehicles. For example, consistent with the disclosed embodiments, thefleet of ridesharing vehicles may include more than 10 ridesharingvehicles, more than 100 ridesharing vehicles, or more than 1000ridesharing vehicles that pick-up multiple users and drop them off atlocations proximate but other than their desired destinations.

In one embodiment, a system for managing a fleet of ridesharing vehiclesmay comprise a communications interface configured to receive requestsfor shared rides from a plurality of users; memory configured to storeindications of passenger-capacity for specific ridesharing vehicles inthe fleet; and at least one processor configured to receive informationfrom the communications interface, access the memory. The at least oneprocessor may be further configured to assign, to ridesharing vehiclesalready transporting users, additional users for simultaneoustransportation in the ridesharing vehicles; track a current utilizedcapacity of each specific ridesharing vehicle; and implement a thresholdblock that prevents assignment of additional users to a ridesharingvehicle when the ridesharing vehicle's current utilized capacity isabove a threshold being less than the ridesharing vehicle'spassenger-capacity.

In another embodiment, a computer-implemented method for managing afleet of ridesharing vehicles may comprise assigning, to ridesharingvehicles already transporting users, additional users for simultaneoustransportation in the ridesharing vehicles; tracking a current utilizedcapacity of each specific ridesharing vehicle; and implementing athreshold block that prevents assignment of additional users to aridesharing vehicle when the ridesharing vehicle's current utilizedcapacity is above a threshold being less than the ridesharing vehicle'spassenger-capacity.

In one embodiment, an automated ridesharing dispatch system may comprisea communications interface configured to receive ride requests from afirst plurality of communication devices associated with a plurality ofusers and receive location information from a second plurality ofcommunication devices associated with a plurality of ridesharingvehicles. Each ride request may include a starting point and a desireddestination corresponding to each of the plurality of users. The systemmay further comprise at least one processor configured to assign a firstridesharing vehicle to pick-up a first group of the plurality of usersand determine pick-up locations for the first group of users. For atleast some of the first group of users, the determined pick-up locationsmay differ from the starting points. The at least one processor may befurther configured to send data to the at least some of the first groupof users to guide each user to a respective pick-up location differentfrom a corresponding starting point of each said user; use informationreceived from a first communications device of a first user to predictwhen the first user will arrive the assigned first pick-up location;prior to the first user arriving at a first pick-up location, cancel theassignment of the first ridesharing vehicle to the first user whilemaintaining the assignment of the first ridesharing vehicle to others ofthe first group of users; predict when a second ridesharing vehicle maypass the first pick-up location; compare the predicted passing time ofthe second ridesharing vehicle with the arrival time of the first user;and re-assign the first user to the second ridesharing vehicle when thepredicted passing time is after the predicted arrival time.

In another embodiment, a computer-implemented method for automaticallydispatching ridesharing vehicles may comprise receiving ride requestsfrom a first plurality of communication devices associated with aplurality of users and receiving location information from a secondplurality of communication devices associated with a plurality ofridesharing vehicles. Each ride request may include a starting point anda desired destination corresponding to each of the plurality of users.The method may further comprise assigning a first ridesharing vehicle topick-up a first group of the plurality of users and determining pick-uplocations for the first group of users. For at least some of the firstgroup of users, the determined pick-up locations may differ from thestarting points. The method may further comprise sending data to the atleast some of the first group of users to guide each user to arespective pick-up location different from a corresponding startingpoint of each said user; using information received from a firstcommunications device of a first user to predict when the first userwill arrive the assigned first pick-up location; prior to the first userarriving at a first pick-up location, cancelling the assignment of thefirst ridesharing vehicle to the first user while maintaining theassignment of the first ridesharing vehicle to others of the first groupof users; predicting when a second ridesharing vehicle may pass thefirst pick-up location; comparing the predicted passing time of thesecond ridesharing vehicle with the arrival time of the first user; andre-assigning the first user to the second ridesharing vehicle when thepredicted passing time is after the predicted arrival time.

In one embodiment, an automated ridesharing dispatch system may comprisea communications interface configured to receive ride requests from afirst plurality of communication devices associated with a plurality ofusers, wherein each ride request includes a starting point and a desireddestination corresponding to each of the plurality of users; receivelocation information from a second plurality of communication devicesassociated with a plurality of ridesharing vehicles; and at least oneprocessor. The at least one processor may be configured to: assign afirst ridesharing vehicle to pick-up up a group of the plurality ofusers; determine pick-up locations for the group of users, wherein forat least some of the group of the plurality of users, the determinedpick-up locations differ from the starting points; send data to thegroup of the plurality of users indicating appointed pick-up times atthe determined pick-up locations; use information received from at leastone of the plurality of ridesharing vehicles to predict when the firstridesharing vehicle will arrive to a first pick-up location assigned toa first user; prior to a first pick-up time associated with the firstuser, estimate that the first ridesharing vehicle is going to be late tothe first pick-up location by more than a time threshold; identify asecond ridesharing vehicle to be assigned to pick-up the first user;cancel the assignment of the first ridesharing vehicle to the first userwhile maintaining the assignment of the first ridesharing vehicle toothers of the group of the plurality of users; and assign the secondridesharing vehicle to pick up the first user.

In one embodiment, a system for managing a fleet of ridesharing vehiclesmay comprise a communications interface configured to receive requestsfor shared rides from a plurality of users and at least one processor.The at least one processor may be configured to identify a firstridesharing vehicle and a second ridesharing vehicle that are currentlywithout passengers and receive, via the communications interface, afirst request for a shared ride from a first user. The first request mayinclude information related to a first pick-up location of the firstuser and a first desired destination of the first user. The at least oneprocessor may be further configured to receive, via the communicationsinterface, a second request for a shared ride from a second user. Thesecond request may include information related to a second pick-uplocation of the second user and a second desired destination of thesecond user. The at least one processor may be further configured toassign the first user and the second user to the first ridesharingvehicle; generate a route to the first ridesharing vehicle for pickingup and dropping off each of the first user and the second user; andreceive, via the communications interface, a third request for a sharedride from a third user. The third request may include informationrelated to a third pick-up location of the third user and a thirddesired destination of the third user. The at least one processor may befurther configured to calculate a first expected arrival time of thefirst ridesharing vehicle at the third pick-up location and calculate asecond expected arrival time of the second ridesharing vehicle at thethird pick-up location. The second expected arrival time may be soonerthan the first expected arrival time. The at least one processor may befurther configured to, when both the first expected arrival time and thesecond expected arrival time are below a predetermined threshold, assignthe third user to the first ridesharing vehicle; and generate an updatedroute for the first ridesharing vehicle to pick-up the third user.

In another embodiment, a method for managing a fleet of ridesharingvehicles may comprise receiving requests for shared rides from aplurality of users; identifying a first ridesharing vehicle and a secondridesharing vehicle that are currently without passengers; andreceiving, via a communications interface, a first request for a sharedride from a first user. The first request may include informationrelated to a first pick-up location of the first user and a firstdesired destination of the first user. The method may further comprisereceiving, via the communications interface, a second request for ashared ride from a second user. The second request may includeinformation related to a second pick-up location of the second user anda second desired destination of the second user. The method may furthercomprise assigning the first user and the second user to the firstridesharing vehicle; generating a route to the first ridesharing vehiclefor picking up and dropping off each of the first user and the seconduser; and receiving, via the communications interface, a third requestfor a shared ride from a third user. The third request may includeinformation related to a third pick-up location of the third user and athird desired destination of the third user. The method may furthercomprise calculating a first expected arrival time of the firstridesharing vehicle at the third pick-up location and calculating asecond expected arrival time of the second ridesharing vehicle at thethird pick-up location. The second expected arrival time may he soonerthan the first expected arrival time. The method may further comprise,when both the first expected arrival time and the second expectedarrival time are below a predetermined threshold, assigning the thirduser to the first ridesharing vehicle; and generating an updated routefor the first ridesharing vehicle to pick-up the third user.

In one embodiment, an automated ridesharing dispatch system includesmemory configured to store historical data associated with past demandfor ridesharing vehicles in a geographical area, a communicationsinterface, and at least one processor configured to access the memory.The at least one processor is configured to use the historical data topredict imminent demand of ridesharing requests including predictinggeneral zones in the geographical area associated with imminent demandand select a holding zone for prepositioning empty ridesharing vehiclesin order to expedite satisfaction of the predicted imminent demand. Theat least one processor is also configured to send, via thecommunications interface, to a mobile communications device in aspecific ridesharing vehicle, instructions directing the specificridesharing vehicle to the holding zone.

In one embodiment, a non-transitory computer-readable storage mediumstores instructions that, when executed by at least one processor, causethe at least one processor to perform a method for managing a fleet ofridesharing vehicles. The method includes storing historical dataassociated with past demand for ridesharing vehicles in a geographicalarea and using the historical data to predict imminent demand ofridesharing requests including predicting general zones in thegeographical area associated with imminent demand. The method alsoincludes selecting a holding zone for prepositioning empty ridesharingvehicles in order to expedite satisfaction of the predicted imminentdemand and sending to a mobile communications device in a specificridesharing vehicle, instructions directing the specific ridesharingvehicle to the holding zone.

In one embodiment, an automated ridesharing dispatch system includes amemory configured to store historical data associated with past demandfor ridesharing vehicles in a geographical area, a communicationsinterface configured to receive location information from a plurality ofcommunication devices associated with a plurality of ridesharingvehicles, and at least one processor configured to access the memory.The at least one processor is configured to assign, to ridesharingvehicles already transporting users, additional users for simultaneoustransportation in the ridesharing vehicles and to track assignments ofeach specific ridesharing vehicle to identify that a first ridesharingvehicle and a second ridesharing vehicle are about to be withoutpassengers and without future assignments. The at least one processor isalso configured to direct the first ridesharing vehicle to a firstholding zone based on a current location of the first vehicle and apredicted imminent demand proximate the first holding zone and directthe second ridesharing vehicle to a second holding zone other than thefirst holding zone based on a current location of the second vehicle anda predicted imminent demand proximate to the second holding zone.

In one embodiment, an automated ridesharing dispatch system includes acommunications interface configured to receive ride requests from aplurality of users headed to differing destinations, each ride requestincluding a starting point and a desired destination. The communicationsinterface is also configured to receive from a mobile communicationsdevice associated with a ridesharing vehicle, a current location of theridesharing vehicle. At least one processor is configured to in responseto the ride requests, send the ridesharing vehicle to pick up theplurality of users headed to differing destinations and determine, basedon a known passenger capacity of the ridesharing vehicle, a capacitystatus of the ridesharing vehicle. If the capacity status of theridesharing vehicle is below a capacity threshold, the processor directsthe ridesharing vehicle along a first route resulting in a first set ofarrival times for the plurality of users. If the capacity threshold ismet, the processor directs the ridesharing vehicle along a second routeresulting in a second set of arrival times for the plurality of users.The second set of arrival times is earlier than the first set of arrivaltimes.

In one embodiment, a non-transitory computer-readable storage mediumstoring instructions that, when executed by at least one processor,cause the at least one processor to perform a method for managing afleet of ridesharing vehicles. The method includes receiving riderequests from a plurality of users headed to differing destinations,each ride request including a starting point and a desired destination.The method also includes receiving from a mobile communications deviceassociated with a ridesharing vehicle, a current location of theridesharing vehicle and, in response to the ride requests, sending theridesharing vehicle to pick up the plurality of users headed todiffering destinations. The method further includes determining based ona known passenger capacity of the ridesharing vehicle, a capacity statusof the ridesharing vehicle. If the capacity status of the ridesharingvehicle is below a capacity threshold, the ridesharing, vehicle isdirected along a first route resulting in a first set of arrival timesfor the plurality of users. If the capacity threshold is met, theridesharing vehicle is directed along a second route resulting in asecond set of arrival times for the plurality of users. The second setof arrival times are earlier than the first set of arrival times,

In one embodiment, an automated ridesharing dispatch system includes acommunications interface configured to receive ride requests from aplurality of users headed to differing destinations, each ride requestincluding a starting point and a desired destination, and to receivefrom a mobile communications device associated with a ridesharingvehicle, a current location of the ridesharing vehicle. At least oneprocessor is configured to in response to the ride requests, send theridesharing vehicle to pick up the plurality of users headed todiffering destinations, to_determine based on a known passenger capacityof the ridesharing vehicle, a capacity status of the ridesharingvehicle, and to_direct the ridesharing vehicle along at least one of afirst route and a second route based on a comparison of the capacitystatus of the ridesharing vehicle to a capacity threshold. The firstroute results in a first set of arrival times for the plurality ofusers, the second route results in a second set of arrival times for theplurality of users, and the second set of arrival times are earlier thanthe first set of arrival times.

In one embodiment, an automated ridesharing dispatch system isdisclosed. The system may include a communications interface, a memory,a plurality of communication devices, a plurality of ridesharingvehicles, and at least one processor. The communications interface maybe configured to receive ride requests from a plurality of users,wherein each ride request includes a starting point and a desireddestination, and receive from a plurality of communication devicesassociated with a plurality of ridesharing vehicles, indications ofcurrent locations of the plurality of ridesharing vehicles. The memorymay be configured to store a plurality of rules including a rule toselect a fastest route for guiding a ridesharing vehicle, and a rule forreducing backtracking, even in instances where backtracking would resultin shorter travel time. The at least one processor may be configured toassign the plurality of users to a common ridesharing vehicle and to usethe stored plurality of rules to determine a route for the ridesharingvehicle other than the fastest route. The determined route is selectedto account for the rule for reducing backtracking and includes aplurality of pick-up and drop-off locations associated with the startingpoints and desired destinations of the plurality of users. The at leastone processor may also be configured in order to reduce backtracking, todirect the ridesharing vehicle along the determined route other than thefastest route.

In one embodiment, a method is disclosed for managing a fleet ofridesharing vehicles. The method may be performed by a system includinga communications interface, a plurality of communication devices, aplurality of ridesharing vehicles, a memory, and at least one processor.The method may include receiving ride requests from a plurality ofusers, wherein each ride request includes a starting point and a desireddestination; receiving from a plurality of communication devicesassociated with a plurality of ridesharing vehicles, indications ofcurrent locations of the plurality of ridesharing vehicles; accessingmemory configured to store a plurality of rules including a rule toselect a fastest route for guiding a ridesharing vehicle and a rule forreducing backtracking, even in instances where backtracking would resultin shorter travel time; assigning the plurality of users to a commonridesharing vehicle; using the stored plurality of rules to determine aroute for the ridesharing vehicle other than the fastest route, thedetermined route is selected to account for the rule for reducingbacktracking and includes a plurality of pick-up and drop-off locationsassociated with the starting points and desired destinations of theplurality of users; and in order to reduce backtracking, directing theridesharing vehicle along the determined route other than the fastestroute,

In one embodiment, a system for directing a vehicle-for-hire and aprospective passenger to a remote pick-up location to avoid trafficcongestion is disclosed. The system may include a communicationsinterface, a plurality of communication devices, a plurality ofvehicles-for-hire, and at least one processor. The communicationsinterface may be configured to receive a ride request from a user,wherein the ride request includes a starting point and a desireddestination, and receive from the plurality of communication devicesassociated with the plurality of vehicles-for-hire indications ofcurrent locations of the plurality of vehicles-for-hire. The at leastone processor may be configured to receive real time traffic data,including information about at least one of street blockages andatypical congestion, identify an existence of an area of trafficobstruction in a vicinity of the user's starting point, select avehicle-for-hire to pick up the user, and identify a pick-up location,remote from the user's starting point, peripheral to the area of trafficobstruction. The at least one processor may be configured to send to theuser, via the communications interface, information about the pick-uplocation, and send to the selected vehicle-for-hire, via thecommunications interface, driving directions to the pick-up location,wherein the driving directions substantially avoid the area of trafficobstruction.

In one embodiment, a method is disclosed for directing avehicle-for-hire and a prospective passenger to a remote pick-uplocation to avoid traffic congestion. The method may be performed by acommunications interface, a plurality of communication devices, aplurality of vehicles-for-hire, and at least one processor. The methodmay include receiving a ride request from a user, wherein the riderequest includes a starting point and a desired destination, receivingfrom the plurality of communication devices associated with theplurality of vehicles-for-hire indications of current locations of theplurality of vehicles-for-hire, receiving real time traffic data,including information about at least one of street blockages andatypical congestion, identifying an existence of an area of trafficobstruction in a vicinity of the user's starting point, selecting avehicle-for-hire to pick up the user, identifying a pick-up location,remote from the user's starting point, and peripheral to the area oftraffic obstruction, sending to the user, via the communicationsinterface, information about the pick-up location, and sending to theselected vehicle-for-hire, via the communications interface, drivingdirections to the pick-up location, wherein the driving directionssubstantially avoid the area of traffic obstruction.

In one embodiment, a system is disclosed for directing avehicle-for-hire and a prospective passenger to a remote pick-uplocation to avoid traffic congestion. The system may include acommunications interface, a plurality of communication devices, aplurality of vehicles-for-hire, and at least one processor. Thecommunications interface may be configured to receive from the pluralityof communication devices associated with the plurality ofvehicles-for-hire indications of current locations of the plurality ofvehicles-for-hire. The at least one processor may be configured toreceive real time traffic data, including information about at least oneof street blockages and atypical congestion, identify an existence of anarea of traffic obstruction in a vicinity of the user's starting point,select a vehicle-for-hire to pick up the user, identify a drop-offlocation, remote from the user's desired destination, peripheral to thearea of traffic obstruction, send to the selected vehicle-for-hire, viathe communications interface, driving directions to the drop-offlocation, wherein the driving directions substantially avoid the area oftraffic obstruction, and send to the user, via the communicationsinterface, walking directions from the drop-off location to the desireddestination.

In one embodiment, an automated ridesharing dispatch system isdisclosed. The system may include a communications interface configuredto electronically receive ride requests from a plurality of users, amemory configured to store a capacity threshold for each of a pluralityof ridesharing vehicles, at least one sensor, and at least oneprocessor. The processor may be configured to process the ride requestsreceived from the communications interface and to assign to a singleridesharing vehicle the plurality of users for pick up at a plurality ofdiffering pick-up locations and for delivery to a plurality of differingdrop-off locations. The processor may be configured to determine a routefor the ridesharing vehicle, receive from at least one sensor within theridesharing vehicle, information indicative of a current number ofpassengers in the ridesharing vehicle, and determine whether to assignadditional users to the ridesharing vehicle based on the receivedinformation from the sensor and the capacity threshold associated withthe ridesharing vehicle.

In one embodiment, a method is disclosed for automatically dispatchingridesharing vehicles. The method may be performed by a communicationsinterface configured to electronically receive ride requests from aplurality of users, a memory configured to store a capacity thresholdfor each of a plurality of ridesharing vehicles, at least one sensor,and at least one processor. The method may include storing a capacitythreshold for each of a plurality of ridesharing vehicles, receivingride requests from a plurality of users, assigning to a particularridesharing vehicle the plurality of users for pick up at a plurality ofdiffering pick-up locations and for delivery to a plurality of differingdrop-off locations, determining a route for the ridesharing vehicle,receiving at a location remote from the particular vehicle, and based onsensor data transmitted from the particular vehicle, informationindicative of a current number of passengers in the particular vehicle,comparing the sensor data from the particular vehicle with the capacitythreshold of the particular vehicle, determining, based on comparing,whether a number of actual users within the particular vehicle exceeds anumber of users assigned to die particular vehicle, and reassigning toanother vehicle a subsequent user already assigned to the particularvehicle if, from the sensor data, actual users detected exceeds thenumber of assigned users.

In one embodiment, an autonomous ridesharing vehicle is disclosed. Thevehicle may include a plurality of seats for accommodating a number ofpassengers no greater than a capacity threshold, a communicationsinterface configured to wirelessly communicate with a remote server, atleast one sensor configured to detect a current number of passengers inthe ridesharing vehicle, and at least one processor. The at least oneprocessor may be configured to receive from the remote server a routeincluding a plurality of pick-up locations for picking up users, anumber of the users expected to enter the ridesharing vehicle at eachpick-up location, and a plurality of drop-off locations for deliveringthe users, determine a discrepancy between an actual number ofpassengers entering the ridesharing vehicle at a specific pick-uplocation and the number of users expected to enter the ridesharingvehicle at the specific pick-up location, and inform the remote serverof the discrepancy, thereby causing a change in the route of theridesharing vehicle.

Consistent with other disclosed embodiments, non-transitorycomputer-readable storage media may store program instructions, whichare executed by at least one processing device and perform any of themethods described herein.

The foregoing general description and the following detailed descriptionare exemplary and explanatory only and are not restrictive of theclaims.

BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings, which are incorporated in and constitute pailof this disclosure, illustrate various example embodiments. In thedrawings:

FIG. 1 is a diagram illustrating an example ridesharing managementsystem, in accordance with some embodiments of the present disclosure.

FIG. 2 is a diagram illustrating the components of an example mobilecommunications device associated with a ridesharing management system,in accordance with some embodiments of the present disclosure.

FIG. 3 is a diagram illustrating the components of an exampleridesharing management server associated with a ridesharing managementsystem, in accordance with some embodiments of the present disclosure.

FIGS. 4A and 4B are flowcharts of example processes for vehicleridesharing management, in accordance with some embodiments of thepresent disclosure.

FIG. 5 is a diagram of example timelines showing ridesharingarrangements, in accordance with some embodiments of the presentdisclosure.

FIG. 6 is a diagram of an example memory module for under-utilizingvehicle capacity, in accordance with some embodiments of the presentdisclosure.

FIG. 7 is a diagram of example timelines showing the use of thresholdblocks in a rideshare fleet, in accordance with some embodiments of thepresent disclosure.

FIG. 8 is a diagram of a flowchart of an example process for managing afleet of ridesharing vehicles, in accordance with some embodiments ofthe present disclosure.

FIG. 9 is a diagram of an example memory module for dynamicre-assignment of ridesharing vehicles, in accordance with someembodiments of the present disclosure.

FIG. 10A is a diagram of example timelines showing the use of dynamicre-assignment in a rideshare fleet, in accordance with some embodimentsof the present disclosure.

FIG. 10B is a diagram of additional example timelines showing the use ofdynamic re-assignment in a rideshare fleet, in accordance with someembodiments of the present disclosure.

FIG. 11A is a diagram of the first part of another example process formanaging a fleet of ridesharing vehicles, in accordance with someembodiments of the present disclosure.

FIG. 11B is a diagram of the second part of the example process of FIG.11A.

FIG. 11C is a diagram of the first part of yet another example processfor managing a fleet of ridesharing vehicles, in accordance with someembodiments of the present disclosure.

FIG. 11D is a diagram of the second part of the example process of FIG.11C.

FIG. 12 is a diagram of an example memory module for sub-optimization ofroutes in a rideshare fleet, in accordance with sonic embodiments of thepresent disclosure.

FIG. 13A is a diagram illustrating the first part of yet another exampleprocess for managing a fleet of ridesharing vehicles, in accordance withsome embodiments of the present disclosure.

FIG. 13B is a diagram illustrating the second part of the exampleprocess of FIG. 13A.

FIG. 13C is a diagram illustrating an example of scheduling picking up athird user after dropping off a first user and before dropping off asecond user and of sub-optimizing a drop-off location of the first userto minimize a total waiting time of the third user, in accordance withsome embodiments of the present disclosure.

FIG. 13D is a diagram illustrating an example of scheduling picking up athird user after dropping off a first user and before dropping off asecond user and of sub-optimizing a third pick-up location of the thirduser to minimize a total travel time of the first and second users, inaccordance with some embodiments of the present disclosure.

FIG. 13E is a diagram illustrating an example of scheduling picking, upa third user before dropping off a first user and of sub-optimizing athird pick-up location of the third user to minimize a total travel timeof the first and second users, in accordance with some embodiments ofthe present disclosure.

FIG. 13F is a diagram illustrating an example of scheduling picking up athird user before dropping off a first user and of sub-optimizing adrop-off location of the first user to minimize a total waiting time ofthe third user, in accordance with some embodiments of the presentdisclosure.

FIG. 14A is a diagram of the first part of yet another example processfor managing a fleet of ridesharing vehicles, in accordance with someembodiments of the present disclosure.

FIG. 14B is a diagram illustrating the second part of the exampleprocess of FIG. 14A.

FIG. 15 illustrates an exemplary embodiment of a memory containingsoftware modules, in accordance with some embodiments of the presentdisclosure.

FIG. 16 shows an example environment and operation of the automatedridesharing system in the environment, in accordance with someembodiments of the present disclosure.

FIG. 17A is a flowchart illustrating an exemplary method for dispatchingat least one ridesharing vehicle, in accordance with some embodiments ofthe present disclosure.

FIG. 17B is a flowchart illustrating an exemplary method for dispatchinga plurality of ridesharing vehicles, in accordance with some embodimentsof the present disclosure.

FIG. 18 illustrates an exemplary embodiment of a memory containingsoftware modules, in accordance with some embodiments of the presentdisclosure.

FIG. 19 shows an example environment and operation of the automatedridesharing system in the environment, in accordance with someembodiments of the present disclosure.

FIG. 20 is a flowchart illustrating an exemplary method for dispatchingat least one ridesharing vehicle, in accordance with some embodiments ofthe present disclosure.

FIG. 21A illustrates an exemplary embodiment of a memory containingsoftware modules consistent with the present disclosure.

FIG. 21B and 21C are schematic illustrations of an example map includingdifferent driving route alternatives for a ridesharing vehicle accordingto disclosed embodiments.

FIG. 22 is a flowchart of an example process used by ridesharingmanagement system to select between the different route alternatives fora ridesharing vehicle.

FIG. 23 is a flowchart of an example of a method for managing a fleet ofridesharing vehicles.

FIG. 24 illustrates an exemplary embodiment of a memory containingsoftware modules consistent with the present disclosure.

FIG. 25 is a schematic illustration of an example of a map including mapinformation used for ridesharing purposes according to a disclosedembodiment.

FIG. 26 is a flowchart of an example of a method for directing avehicle-for-hire and a prospective passenger to a pick-up or drop-offlocation to avoid traffic congestion.

FIG. 27 illustrates an exemplary embodiment of a memory containingsoftware modules consistent with the present disclosure.

FIG. 28A is a schematic illustration of an example of an interior of avehicle used for ridesharing purposes according to a disclosedembodiment.

FIG. 28B is a schematic illustration of an example of an interior of avehicle used for ridesharing purposes according to a disclosedembodiment.

FIG. 29A is a flowchart of an example of a method for automaticallydispatching ridesharing vehicles.

FIG. 29B is a flowchart of an example of a method for automaticallydispatching ridesharing vehicles.

FIG. 29C is a flowchart of an example of a method for changing a routefor an autonomous ridesharing vehicle.

DETAILED DESCRIPTION

The following detailed description refers to the accompanying drawings.Wherever possible, the same reference numbers are used in the drawingsand the following description to refer to the same or similar parts.While several illustrative embodiments are described herein,modifications, adaptations and other implementations are possible. Forexample, substitutions, additions or modifications may be made to thecomponents illustrated in the drawings, and the illustrative methodsdescribed herein may be modified by substituting, reordering, removing,or adding steps to the disclosed methods. Accordingly, the followingdetailed description is not limited to the disclosed embodiments andexamples. Instead, the proper scope is defined by the appended claims.

Disclosed embodiments of the present disclosure provide methods andsystems for vehicle ridesharing and vehicle ridesharing management. Theterm “vehicle” or “ridesharing vehicle” as used herein refers to anykind of vehicle (e.g., car, van, SUV, truck, bus, etc.) suitable forhuman transportation, such as providing ride services. In someembodiments, a vehicle may be a taxi. In some embodiments, a vehicle mayinclude an autonomous vehicle, wherein a control device integrated withthe vehicle or a management system separate front the vehicle may sendoperational instructions and guide the vehicle to designated pick-uplocations and drop-off locations. For the ease and conciseness ofdescription, some embodiments disclosed herein may simply refer to avehicle or a taxi as an example, which does not limit the scope of thedisclosed embodiments.

Consistent with some embodiments of the present disclosure, aridesharing management system may receive a first ride request from afirst user. The first ride request may include a starting point and adesired destination. The ridesharing management system may calculate afirst estimated pick-up time based on a current location of a vehiclethat is in the surrounding areas. After sending a confirmation with theestimated pick-up time, the ridesharing management system may then guidethe vehicle to a pick-up location for picking up the first rider. Thepick-up location may be a different location from the starting pointincluded in the first ride request. The system may also guide the firstuser to the pick-up location.

In sonic embodiments, the system may subsequently receive a second riderequest from a second user, for example, while the first user is stillin the vehicle. The second ride request may include a second startingpoint and a second desired destination. The system may calculate asecond estimated pick-up time, provide a second confirmation to thesecond rider, and guide the second rider to a second pick-up location.In some embodiments, the second pick-up location may be a differentlocation from the second starting point included in the second riderequest.

In some embodiments, the system may calculate the fares for each user,based on the solo ride portion for a corresponding user, and the sharedportion of the ride. For example, the system may offer a discount forthe shared portion of the ride. In some embodiments, the system may alsocalculate the fare amount for a particular user based on variousservice-related parameters such as user input regarding whether to usetoll roads, the walking distance between the starting point and thepick-up location, and the walking distance between the desireddestination and the drop-off location.

The embodiments herein further include computer-implemented methods,tangible non-transitory computer-readable mediums, and systems. Thecomputer-implemented methods can be executed, for example, by at leastone processor that receives instructions from a non-transitorycomputer-readable storage medium. Similarly, systems and devicesconsistent with the present disclosure can include at least oneprocessor and memory, and the memory can be a non-transitorycomputer-readable storage medium. As used herein., a “non-transitorycomputer-readable storage medium” refers to any type of physical memoryon which information or data readable by at least one processor can bestored. Examples include random access memory (RAM), read-only memory(ROM), volatile memory, nonvolatile memory, hard drives, CD ROMs, DVDs,flash drives, disks, and any other known physical storage medium.Singular terms, such as “memory” and “computer-readable storage medium,”can additionally refer to multiple structures, such a plurality ofmemories or computer-readable storage mediums. As referred to herein, a“memory” may comprise any type of computer-readable storage mediumunless otherwise specified. A computer-readable storage medium may storeinstructions for execution by at least one processor, includinginstructions for causing the processor to perform steps or stagesconsistent with an embodiment herein. Additionally, one or morecomputer-readable storage mediums may be used in implementing acomputer-implemented method. The term “computer-readable storage medium”should be understood to include tangible items and exclude carrier wavesand transient signals.

FIG. 1 is a diagram illustrating an example ridesharing managementsystem, in which various implementations as described herein may bepracticed, according to some embodiments of the present disclosure. Asshown in FIG. 1, ridesharing management system 100 includes one or moremobile communications devices 120A-120F (collectively referred to asmobile communications devices 120), a network 140, a ridesharingmanagement server 150, and a database 170. The plurality of mobilecommunications devices 120A-120F may further include a plurality of userdevices 120A-120C associated with users 130A-130C respectively, aplurality of driver devices 120D and 120E associated with drivers 130Dand 130E, and a driving-control device 120F associated with anautonomous vehicle 130F. Consistent with some embodiments of the presentdisclosure, ridesharing management server 150 may communicate withdriving-control device 120F to direct autonomous vehicle 130F to pick-upand drop-off users 130A-130C. In one example, autonomous vehiclescapable of detecting objects on the road and navigate to designatedlocations may be utilized for providing ridesharing services,

The components and arrangements shown in FIG. 1 are not intended tolimit the disclosed embodiments, as the system components used toimplement the disclosed processes and features can vary. For example,ridesharing management system 100 may include multiple ridesharingmanagement servers 150, and each ridesharing management server 150 mayhandle a certain category of ridesharing services, ridesharing servicesassociated with a certain category of service vehicles, or ridesharingservices in a specific geographical region, such that a plurality ofridesharing management servers 150 may collectively provide a dynamicand integrated ridesharing service system.

Network 140 may facilitate communications between user devices 120 andridesharing management server 150, for example, receiving ride requestsand other ride server related input from or sending confirmations touser devices, and sending ride service assignments to driver devices anddriving-control devices. Network 140 may be any type of networks thatprovides communications, exchanges information, and/or facilitates theexchange of information between ridesharing management server 150 anduser devices 120. For example, network 140 may be the Internet, a LocalArea Network, a cellular network, a public switched telephone network(“PSTN”), or other suitable connection(s) that enables ridesharingmanagement system 100 to send and receive information between thecomponents of ridesharing management system 100. Network 140 may supporta variety of messaging formats, and may further support a variety ofservices and applications for user devices 120. For example, network 140may support navigation services for mobile communications devices 120,such as directing the users and service vehicles to pick-up or drop-offlocations.

Ridesharing management server 150 may be a system associated with acommunication service provider which provides a variety of data orservices, such as voice, messaging, real-time audio/video, to users,such as users 130A-130E. Ridesharing management server 150 may be acomputer-based system including computer system components, desktopcomputers, workstations, tablets, handheld mobile communicationsdevices, memory devices, and/or internal network(s) connecting thecomponents. Ridesharing management server 150 may be configured toreceive information from mobile communications devices 120 over network140, process the information, store the information, and/or transmitinformation to mobile communications devices 120 over network 140.

For example, in some embodiments, ridesharing management server 150 maybe configured to: receive ride requests from user devices 120A-120C,send ride confirmation and ride fare information to user devices120A-120C, and send ride service assignments (for example, includingpick-up and drop-off location information) to driver devices 120D and120E, and driving-control device 120F. Further, ridesharing managementserver 150 may further be configured to receive user input from userdevices 120A-120C as to various ride service parameters, such as walkingdistance to a pick-up location, maximum delay of arrival/detour, andmaximum number of subsequent pick-ups, etc. In some embodiments,ridesharing management server 150 may be further configured to:calculate ride fares based on a solo portion of a user's ride and ashared portion of the ride. Further, the ride fare calculation mayfurther be based on various ride service parameters set by the user,such as the walking distance involved in the ride, and user selectionregarding toll road usage, etc.

Database 170 may include one or more physical or virtual storagescoupled with ridesharing management server 150. Database 170 may beconfigured to store user account information (including registered useraccounts and driver accounts), corresponding user profiles such ascontact information, profile photos, and associated mobilecommunications device information. With respect to users, user accountinformation may further include ride history, service feedbacks,complaints, or comments. With respect to drivers, user accountinformation may farther include number of ride service assignmentscompleted, ratings, and ride service history information. Database 170may further be configured to store various ride requests received fromuser devices 120A-120C and corresponding starting point and desireddestination information, user input regarding various serviceparameters, pick-up and drop-off locations, time of pick-up anddrop-off, ride fares, and user feedbacks, etc.

Database 170 may further include traffic data, maps, and toll roadinformation, which may be used for ridesharing service management.Traffic data may include historical traffic data and real-time trafficdata regarding a certain geographical region, and may be used to, forexample, calculate estimate pick-up and drop-off times, and determine anoptimal route for a particular ride. Real-time traffic data may bereceived from a real-time traffic monitoring system, which may beintegrated in or independent from ridesharing management system 100.Maps may include map information used for navigation purposes, forexample, for calculating potential routes and guiding the users to apick-off or drop-off location. Toll road information may include tollcharges regarding certain roads, and any change or updates thereof. Tollroad information may be used to calculate ride fares, for example, incases where the user permits use of toll roads.

The data stored in database 170 may be transmitted to ridesharingmanagement server 150 for accommodating ride requests. In someembodiments, database 170 may be stored in a cloud-based server (notshown) that is accessible by ridesharing management server 150 and/ormobile communications devices 120 through network 140. While database170 is illustrated as an external device connected to ridesharingmanagement server 150, database 170 may also reside within ridesharingmanagement server 150 as an internal component of ridesharing managementserver 150.

As shown in FIG. 1, users 130A-130E may include a plurality of users130A-130C, and a plurality of drivers 130D and 130E, who may communicatewith one another, and with ridesharing management server 150 usingvarious types of mobile communications devices 120. As an example, amobile communications device 120 may include a display such as atelevision, tablet, computer monitor, video conferencing console, orlaptop computer screen. A mobile communications device 120 may furtherinclude video/audio input devices such as a microphone, video camera,keyboard, web camera, or the like. For example, a mobile communicationsdevice 120 may include mobile devices such as a tablet or a smartphonehaving display and video/audio capture capabilities. A mobilecommunications device 120 may also include one or more softwareapplications that facilitate the mobile communications devices to engagein communications, such as IM, VolP, video conferences. For example,user devices 130A-130C may send requests to ridesharing managementserver 150, and receive confirmations therefrom. Drivers 130D and 130Emay use their respective devices to receive ride service assignments andnavigation information from ridesharing management server 150, and maycontact the users with their respective devices 120D and 120E.

In some embodiments, a user may directly hail a vehicle by hand gestureor verbal communication, such as traditional street vehicle hailing. Insuch embodiments, once a driver accepts the request, the driver may thenuse his device to input the ride request information. Ridesharingmanagement server 150 may receive such request information, andaccordingly assign one or more additional ride service assignments tothe same vehicle, for example, subsequent e-hail ride requests receivedfrom other mobile communications devices 120 through network 140.

In some embodiments, driver devices 120D and 120E, and driving-controldevice 120F may be embodied in a vehicle control panel, as a part of thevehicle control system associated with a particular vehicle. Forexample, a traditional taxi company may install a drive device in alltaxi vehicles managed by the taxi company. In some embodiments, driverdevices 120D and 120E, and driving-control device 120F, may be furthercoupled with a payment device, such as a card reader installed as a partof the vehicle control panel or as a separate device associated with thevehicle. A user may then use the payment device as an alternativepayment mechanism. For example, a user who hails the taxi on the streetmay pay through the payment device, without using a user deviceproviding ridesharing service.

FIG. 2 is a diagram illustrating the components of an example mobilecommunications device 200 associated with a ridesharing managementsystem, such as system 100 as shown in FIG. 1, in accordance with someembodiments of the present disclosure. Mobile communications device 200may be used to implement computer programs, applications, methods,processes, or other software to perform embodiments described in thepresent disclosure, such as mobile communications devices 120A-120F. Forexample, user devices 120A-120C, driver devices 120D and 120E, anddriving-control device 120F may respectively be installed with a userside ridesharing application, and a corresponding driver sideridesharing application.

Mobile communications device 200 includes a memory interface 202, one ormore processors 204 such as data processors, image processors and/orcentral processing units, and a peripherals interface 206. Memoryinterface 202, one or more processors 204, and/or peripherals interface206 can be separate components or can be integrated in one or moreintegrated circuits. The various components in mobile communicationsdevice 200 may be coupled by one or more communication buses or signallines.

Sensors, devices, and subsystems can be coupled to peripherals interface206 to facilitate multiple functionalities. For example, a motion sensor210, a light sensor 212, and a proximity sensor 214 may be coupled toperipherals interface 206 to facilitate orientation, lighting, andproximity functions. Other sensors 216 may also be connected toperipherals interface 206, such as a positioning system (e.g., UPSreceiver), a temperature sensor, a biometric sensor, or other sensingdevice, to facilitate related functionalities. A GPS receiver may beintegrated with, or connected to, mobile communications device 200. Forexample, a GPS receiver may be included in mobile telephones, such assmartphone devices. GPS software may allow mobile telephones to use aninternal or external GPS receiver (e.g., connecting via a serial port orBluetooth). A camera subsystem 220 and an optical sensor 222, e.g., acharged coupled device (“CCD”) or a complementary metal-oxidesemiconductor (“CMOS”) optical sensor, may be used to facilitate camerafunctions, such as recording photographs and video clips.

Communication functions may be facilitated through one or morewireless/wired communication subsystems 224, which includes a Ethernetport, radio frequency receivers and transmitters and/or optical (e.g.,infrared) receivers and transmitters. The specific design andimplementation of wireless/wired communication subsystem 224 may dependon the communication network(s) over which mobile communications device200 is intended to operate. For example, in some embodiments, mobilecommunications device 200 may include wireless/wired communicationsubsystems 224 designed to operate over a GSM network, a CPRS network,an EDGE network, a Wi-Fi or WiMax network, and a Bluetooth® network.

An audio subsystem 226 may be coupled to a speaker 228 and a microphone230 to facilitate voice-enabled functions, such as voice recognition,voice replication, digital recording, and telephony functions.

I/O subsystem 240 may include touch screen controller 242 and/or otherinput controller(s) 244. Touch screen controller 242 may be coupled totouch screen 246. Touch screen 246 and touch screen controller 242 may,for example, detect contact and movement or break thereof using any of aplurality of touch sensitivity technologies, including but not limitedto capacitive, resistive, infrared, and surface acoustic wavetechnologies, as well as other proximity sensor arrays or other elementsfor determining one or more points of contact with touch screen 246.While touch screen 246 is shown in FIG. 2, I/O subsystem 240 may includea display screen (e.g., CRT or LCD) in place of touch screen 246.

Other input controller(s) 244 may be coupled to other input/controldevices 248, such as one or more buttons, rocker switches, thumb-wheel,infrared port, USB port, and/or a pointer device such as a stylus. Touchscreen 246 may, for example, also be used to implement virtual or softbuttons and/or a keyboard.

Memory interface 202 may be coupled to memory 250. Memory 250 includeshigh-speed random access memory and/or non-volatile memory, such as oneor more magnetic disk storage devices, one or more optical storagedevices, and/or flash memory (e.g., NAND, NOR). Memory 250 may store anoperating system 252, such as DRAWN, RTXC, LINUX, iOS, UNIX, OS X,WINDOWS, or an embedded operating system such as VXWorkS. Operatingsystem 252 may include instructions for handling basic system servicesand for performing hardware dependent tasks. In some implementations,operating system 252 can be a kernel (e.g., UNIX kernel).

Memory 250 may also store communication instructions 254 to facilitatecommunicating with one or more additional devices, one or more computersand/or one or more servers. Memory 250 can include graphical userinterface instructions 256 to facilitate graphic user interfaceprocessing; sensor processing instructions 258 to facilitatesensor-related processing and functions; phone instructions 260 tofacilitate phone-related processes and functions; electronic messaginginstructions 262 to facilitate electronic-messaging related processesand functions; web browsing instructions 264 to facilitate webbrowsing-related processes and functions; media processing instructions266 to facilitate media processing-related processes and functions;GPS/navigation instructions 268 to facilitate GPS and navigation-relatedprocesses and instructions; camera instructions 270 to facilitatecamera-related processes and functions; and/or other softwareinstructions 272 to facilitate other processes and functions,

In some embodiments, communication instructions 254 may include softwareapplications to facilitate connection with ridesharing management server150 that handles vehicle ridesharing requests. Graphical user interfaceinstructions 256 may include a software program that facilitates a userassociated with the mobile communications device to receive messagesfrom ridesharing management server 150, provide user input, and so on.For example, a user may send ride requests and ride service parametersto ridesharing management server 150 and receive ridesharing proposalsand confirmation messages. A driver may receive ride service assignmentsfrom ridesharing management server 150, and provide ride service statusupdates.

Each of the above identified instructions and applications maycorrespond to a set of instructions for performing one or more functionsdescribed above. These instructions need not be implemented as separatesoftware programs, procedures, or modules. Memory 250 may includeadditional instructions or fewer instructions. Furthermore, variousfunctions of mobile communications device 200 may be implemented inhardware and/or in software, including in one or more signal processingand/or application specific integrated circuits.

FIG. 3 is a diagram illustrating the components of an example anautomated ridesharing dispatch system 300 that includes ridesharingmanagement server 150 associated with a ridesharing management system100, in accordance with some embodiments of the present disclosure.Ridesharing management server 150 may include a bus 302 (or othercommunication mechanism), which interconnects subsystems and componentsfor transferring information within ridesharing management server 150.

As shown in FIG. 3, automated ridesharing dispatch system 300 mayinclude one or more processors 310, one or more memories 320 storingprograms 330 including, for example, server app(s) 332, operating system334, and data 340, and a communications interface 360 (e.g., a modem,Ethernet card, or any other interface configured to exchange data with anetwork, such as network 140 in FIG. 1). Automated ridesharing dispatchsystem 300 may communicate with an external database 170 (which, forsome embodiments, may be included within ridesharing management server150). Automated ridesharing dispatch system 300 may include a singleserver (e.g., ridesharing management server 150) or may be configured asa distributed computer system including multiple servers, server farms,clouds, or computers that interoperate to perform one or more of theprocesses and functionalities associated with the disclosed embodiments.The term “cloud server” refers to a computer platform that providesservices via a network, such as the Internet. When ridesharingmanagement server 150 is a cloud server it may use virtual machines thatmay not correspond to individual hardware. Specifically, computationaland/or storage capabilities may be implemented by allocating appropriateportions of desirable computation/storage power from a scalablerepository, such as a data center or a distributed computingenvironment.

Processor 310 may be one or more processing devices configured toperform functions of the disclosed methods, such as a microprocessormanufactured by Intel™ or manufactured by AMD™. Processor 310 maycomprise a single core or multiple core processors executing parallelprocesses simultaneously. For example, processor 310 may be a singlecore processor configured with virtual processing technologies. Incertain embodiments, processor 310 may use logical processors tosimultaneously execute and control multiple processes. Processor 310 mayimplement virtual machine technologies, or other technologies to providethe ability to execute, control, run, manipulate, store, etc. multiplesoftware processes, applications, programs, etc. In some embodiments,processor 310 may include a multiple-core processor arrangement (e.g.,dual, quad core, etc.) configured to provide parallel processingfunctionalities to allow ridesharing management server 150 to executemultiple processes simultaneously. It is appreciated that other types ofprocessor arrangements could be implemented that provide for thecapabilities disclosed herein.

Memory 320 may be a volatile or non-volatile, magnetic, semiconductor,tape, optical, removable, non-removable, or other type of storage deviceor tangible or non-transitory computer-readable medium that stores oneor more program(s) 330 such as server apps 332 and operating system 334,and data 340. Common forms of non-transitory media include, for example,a flash drive, a flexible disk, hard disk, solid state drive, magnetictape, or any other magnetic data storage medium, a CD-ROM, any otheroptical data storage medium, any physical medium with patterns of holes,a RAM, a PROM, and EPROM, a FLASH-EPROM or any other flash memory,NVRAM, a cache, a register, any other memory chip or cartridge, andnetworked versions of the same.

Ridesharing management server 150 may include one or more storagedevices configured to store information used by processor 310 (or othercomponents) to perform certain functions related to the disclosedembodiments. For example, ridesharing management server 150 may includememory 320 that includes instructions to enable processor 310 to executeone or more applications, such as server apps 332, operating system 334,and any other type of application or software known to be available oncomputer systems. Alternatively or additionally, the instructions,application programs, etc., may be stored in an external database 170(which can also be internal to ridesharing management server 150) orexternal storage communicatively coupled with ridesharing managementserver 150 (not shown), such as one or more database or memoryaccessible over network 140.

Database 170 or other external storage may be a volatile ornon-volatile, magnetic, semiconductor, tape, optical, removable,non-removable, or other type of storage device or tangible ornon-transitory computer-readable medium. Memory 320 and database 170 mayinclude one or more memory devices that store data and instructions usedto perform one or more features of the disclosed embodiments. Memory 320and database 170 may also include any combination of one or moredatabases controlled by memory controller devices (e.g., server(s),etc.) or software, such as document management systems, Microsoft SQLdatabases, SharePoint databases, Oracle™ databases, Sybase™ databases,or other relational databases.

In some embodiments, ridesharing management server 150 may becommunicatively connected to one or more remote memory devices (e.g.,remote databases (not shown)) through network 140 or a differentnetwork. The remote memory devices can be configured to storeinformation that ridesharing management server 150 can access and/ormanage. By way of example, the remote memory devices may includedocument management systems, Microsoft SQL database, SharePointdatabases, Oracle™ databases, Sybase™ databases, or other relationaldatabases. Systems and methods consistent with disclosed embodiments,however, are not limited to separate databases or even to the use of adatabase.

Programs 330 may include one or more software modules causing processor310 to perform one or more functions of the disclosed embodiments.Moreover, processor 310 may execute one or more programs locatedremotely from one or more components of the ridesharing managementsystem 100. For example, ridesharing management server 150 may accessone or more remote programs that, when executed, perform functionsrelated to disclosed embodiments.

In the presently described embodiment, server app(s) 332 may causeprocessor 310 to perform one or more functions of the disclosed methods.For example, devices associated with users, drivers and autonomousvehicles may respectively be installed with user applications forvehicle ridesharing services, and driver applications for vehicleridesharing services. Further, a mobile communications device may beinstalled with both the driver applications and the user applications,for uses in corresponding situations.

In some embodiments, other components of ridesharing management system100 may be configured to perform one or more functions of the disclosedmethods. For example, mobile communications devices 120 may beconfigured to calculate estimate pick-up and drop-off times based on acertain ride request, and may be configured to calculate estimate ridefares. As another example, mobile communications devices 120 may furtherbe configured to provide navigation service, and location service, suchas directing the user to a particular pick-up or drop-off location, andproviding information about a current location of the respective user orvehicle to ridesharing management server 150.

In some embodiments, program(s) 330 may include operating system 334performing operating system functions when executed by one or moreprocessors such as processor 310. By way of example, operating system334 may include Microsoft Windows™, Unix™, Linux™, Apple™ operatingsystems, Personal Digital Assistant (PDA) type operating systems, suchas Apple iOS, Google Android, Blackberry OS, Microsoft CE™, or othertypes of operating systems. Accordingly, the disclosed embodiments mayoperate and function with computer systems running any type of operatingsystem 334. Ridesharing management server 150 may also include softwarethat, when executed by a processor, provides communications with network140 through communications interface 360 and/or a direct connection toone or more mobile communications devices 120. Specifically,communications interface 360 may be configured to receive ride requests(e.g., from user devices 120A -120C) headed to differing destinations,and receive indications of the current locations of the ridesharingvehicles (e.g., from driver devices 120D and 120E or driving-controldevice 120F). In one example, communications interface 360 may beconfigured to continuously or periodically receive current vehiclelocation data for the plurality of ridesharing vehicles that are part ofridesharing management system 100. The current vehicle location data mayinclude global positioning system (GPS) data generated by at least oneGPS component of a mobile communications device 120 associated with eachridesharing vehicle,

In some embodiments, data 340 may include, for example, profiles ofusers, such as user profiles or driver profiles. Data 340 may furtherinclude ride requests from a plurality of users, user ride history anddriver service record, and communications between a driver and a userregarding a particular ride request. In some embodiments, data 340 mayfurther include traffic data, toll road information, and navigationinformation, which may be used for handling and accommodating riderequests.

Automated ridesharing dispatch system 300 may also include one or moreI/O devices 350 having one or more interfaces for receiving signals orinput from devices and providing signals or output to one or moredevices that allow data to be received and/or transmitted by automatedridesharing dispatch system 300. For example, automated ridesharingdispatch system 300 may include interface components for interfacingwith one or more input devices, such as one or more keyboards, mousedevices, and the like, that enable automated ridesharing dispatch system300 to receive input from an operator or administrator (not shown).

FIGS. 4A and 4B are flowcharts of example processes 410 and 420 forvehicle ridesharing management, in accordance with some embodiments ofthe present disclosure. In one embodiment, all of the steps of process400 may be preformed by a ridesharing management server, such asridesharing management server 150 described above with reference toFIGS. 1 and 3. Alternatively, at least some of the steps of process 400may be performed by a mobile communications device, such as the mobilecommunications devices 120 described above with reference to FIGS. 1 and2. In the following description, reference is made to certain componentsof FIGS. 1-3 for purposes of illustration. It will be appreciated,however, that other implementations are possible and that othercomponents may be utilized to implement example methods disclosedherein.

At step 411, ridesharing management server 150 may receive a first riderequest from a first wireless communication of a first user, forexample, a request from user 130A sent through user device 120A. Thefirst ride request may include a first starting point and a firstdesired destination. A ride request may refer to a request from a userneeding transportation service from a certain location to another. Astarting point may refer to a current location of the user, as input bythe user through an input device of an associated user device, or asdetermined by a location service application installed on the userdevice. In some embodiments, the starting point may be a locationdifferent from the current location of the user, for example, a locationwhere the user will subsequently arrive at (e.g., entrance of abuilding). A desired destination may refer to a location where the userrequests to be taken to.

In some embodiments, the actual pick-up location and the actual drop-offlocation may be different from the starting point and the desireddestination. For example, the pick-up location may be of a certaindistance from the starting point, where the user may be directed to forpick-up. By encouraging the user to walk to a pick-up location nearby,consistent with some embodiments, the vehicle may more easily andquickly locate the user without excessive detour, or causing excessivedelay for users who are in the vehicle. Similarly, by encouraging theuser to walk from a drop-off location different from but within acertain distance from the desired destination, the vehicle may be ableto accommodate subsequent pick-ups, or arrive at the subsequent pick-uplocations more quickly. The vehicle ridesharing service managementsystem may provide incentives or rewards for the user who are willing towalk a certain distance. For example, the ridesharing management systemmay offer certain discounts based on the number and distances of thewalks involved in a particular ride. Alternatively, the ridesharingmanagement system may offer ride credits corresponding to the number anddistance of the walks undertaken by the user during his rides. The usermay use the credits for subsequent ride payment, or redeem the creditfor money, free rides, or other rewards. Further, advantages of suchembodiments may include more efficient vehicle use and management, moreuser flexibility, and less air pollution associated with vehicle use.

In some embodiments, prior to or after the user sends a ride request toridesharing management server 150, the user may further input rideservice parameters through, for example, a settings component providedon a user interface. Ride service parameters refer to user preferenceparameters regarding a vehicle ridesharing service, for example, amaximum walking distance from the starting point to a pick-up location,a maximum walking distance from a drop-off location to a desireddestination, a total maximum walking distance involved in a ride, amaximum number of subsequent pick-ups, maximum delay of arrival/detourincurred by subsequent pick-ups during a ride, and a selection whetherto permit toll road usage during the ride, etc.

Ride service parameters may be transmitted to ridesharing managementserver 150 for processing the request and assignment of an availablevehicle based on the ride service parameters. For example, a riderequest may be associated with a maximum walking distance of 300 metersfrom a starting point to a pick-up location. When assigning an availablevehicle to pick-up the user, ridesharing management server 150 mayinclude in the assignment an assigned pick-up location within 300 metersor less of the starting point. Similarly, a ride request may beassociated with a maximum walking distance of 0.5 mile from a drop-offlocation to a desired destination. When assigning an available vehicleto pick-up the user, ridesharing management server 150 may include inthe assignment an assigned drop-off location within 0.5 mile or lessfrom the desired destination.

For requests associated with a maximum total walking distance of onemile during the ride, when assigning an available vehicle to pick-up theuser, ridesharing management server 150 may include in the assignment anassigned pick-up location and an assigned drop-off location, a total ofa distance from the starting point to the assigned pick-up location anda distance from the assigned drop-off location to a desired destinationmay be equal to or less than one mile.

In the above examples, the values regarding the walking distances areonly exemplary. Other embodiments consistent with the present disclosuremay use different options of the distances and may provide a list ofoptions. The distances may further be measured in different units, forexample, miles, meters, kilometers, blocks, and feet, etc., which arenot limited by the disclosed embodiments herein. In some embodiments,the distance may further be represented by an average walking time froma certain location to another, based on average walking speed, forexample, ten minutes, five minutes, etc.

With respect to parameters regarding subsequent pick-ups, such as amaximum number of subsequent pick-ups, and maximum delay of arrivalincurred by subsequent pick-ups, ridesharing management server 150 mayassign subsequent pick-ups accordingly, without exceeding the parametersset by the user. For example, a ride request may be associated with amaximum number of two subsequent pick-ups during the ride. Ridesharingmanagement server 150 may monitor the service status of the vehicleassigned to pick-up the user, and refrain from assigning a thirdsubsequent pick-up before the vehicle arrives at the a drop-off locationfor dropping off the user. As another example, for a ride requestassociated with a maximum delay of arrival of ten minutes, whenassigning subsequent ride requests, ridesharing management server 150may calculate an estimated delay that may occur to the user if the samevehicle was to undertake the subsequent ride request. If the estimateddelay that may occur to the user is more than ten minutes, ridesharingmanagement server 150 may assign the subsequent ride request to otheravailable vehicles.

In some embodiments, the user may also input selection of toll roadusage through the associated user device, to allow or disallow use oftoll roads. Ridesharing management server 150 may then take the user'sselection into account when assigning an available vehicle foraccommodating the ride request, determining travel route, andcalculating ride fare for the user. For example, ridesharing managementserver 150 may adjust the ride fare amount for a corresponding userbased on the toll roads selection input and toll charges involved. Foranother example, if a first user does not permit toll road usage, beforeany subsequent pick-ups during the ride, ridesharing management server150 may send a route to an assigned vehicle that does not include tollroads. For another example, if a subsequent user sharing the ridepermits usage of toll road, ridesharing management server 150 may notcharge the first user for any overlap portion of the ride where tollroads are used, change the route to include toll roads after the firstuser is dropped off, or assign the second user to a ridesharing vehiclewith users that permit toll road usage.

In some embodiments, the ride request information may also be input fromthe driver device, for example, driver device 120D, or from a deviceassociated with the vehicle. In the case of street hailing, where theuser hails a vehicle on the street without using a vehicle ridesharingservice application on a mobile communications device, the driver, forexample, driver 130D, may input information such as the startingpoint/pick-up information and destination information through driverdevice 120D, which may then be transmitted to ridesharing managementserver 150.

At step 413, ridesharing management server 150 may calculate anestimated pick-up time, for example, based on a current location of anassigned vehicle and the first starting point included in the first riderequest. An estimated pick-up time may refer to a time period before anassigned vehicle arrives at a pick-up location for picking up the user.

The assigned vehicle may refer to the vehicle that is assigned toundertake the first ride request, for example, a taxi in a taxi fleet,one of a plurality of vehicles managed by a transportation servicesystem, or a plurality of vehicles owned by a plurality of owners andused to provide ridesharing services. The pick-up location may be thesame as the starting point, or an assigned pick-up location associatedwith the starting point.

The estimated pick-up time may be determined based on a distance betweena current location of the assigned vehicle and the pick-up location, andan estimate speed of traveling along the route between the twolocations. The current location of the assigned vehicle may bedetermined by a location service application installed on a driverdevice, a driving-control device, or by a location determinationcomponent in the ridesharing management system 100, which may be a partof or separate from ridesharing management server 150. In someembodiments, the estimated pick-up time may further be determined basedon historical or real-time traffic data, and a route currently followedby the vehicle.

In some embodiments, process 410 may further include locating one or aplurality of potential available vehicles, and selecting an assignedvehicle therefrom. For example, potential available vehicles may includevacant vehicles in the surrounding areas of the first starting point,and vehicles heading to a location close to the first starting point forassigned pick-ups or drop-offs. Ridesharing management server 150 mayfilter potential available vehicles by ride service parameters set bythe users who are inside the vehicle, for example, removing occupiedvehicles where the a user inside the vehicle does not permit subsequentpick-ups, or occupied vehicles where the user requires a minimal delay.In some embodiments, ridesharing management server 150 may filterpotential assignment vehicles by choosing a vehicle that would involveminimal walking of the user, or walking without the need of crossing thestreet. In some embodiments, ridesharing management server 150 mayfurther filter potential assignment vehicles by choosing a vehicle thatwould involve minimal detour for the vehicle to arrive at the pick-uplocation. In some embodiments, the assigned vehicle may be selected byapplying multiple filter criteria, or by applying multiple filtercriteria in a certain order.

In some embodiments, the pick-up location may be an assigned pick-uplocation different from the first starting point, for example, half ablock or further away from the first starting point.

Ridesharing management server 150 may assign a pick-up location based onride service parameters set by the first user, as described above atstep 411. Ridesharing management server 150 may further assign a pick-uplocation which is along a main street where an assigned vehicle caneasily locate, or a location which would not require an assign vehicleto take a U-turn. In cases where there are one or more other users inthe vehicle, ridesharing management server 150 may assign a pick-uplocation close to the vehicle's next assigned drop-off, or on the sideof a street where the vehicle will soon go through. In some embodiments,ridesharing management server 150 may adjust selection of the pick-uplocation based on filtering results of potential assignment vehicles, orvice versa. The two selection processes may complement each other toreach one or more optimal combinations.

In some embodiments, where there are multiple potential assignmentvehicles, each with a corresponding potential pick-up location, anestimated pick-up time may be respectively calculated corresponding toeach of the potential assignment vehicles. Ridesharing management server150 may then choose the vehicle with the shortest estimated pick-up timeto be the assigned vehicle.

At step 415 ridesharing management server 150 may send a first messageto a user device associated with the first user, which is, in thisexample, user device 120A. The first message may be configured to causean indication of the calculated first estimated pick-up time to appearon a display of user device 120A. The message may appear in differentformats, for example, a text message including the estimated pick-uptime, an audio message, or an image, the specific implementation ofwhich are not limited by the disclosed embodiments herein.

In one embodiment, the message includes a confirmation that theridesharing request is accepted. If ridesharing management server 150assigns a pick-up location different from the starting point, themessage may further cause the display of an indication of the assignedpick-up location. Ridesharing management server 150 may further providea navigation option which may be displayed on a user interface. Aselection of the navigation option may then provide walking directionsthe user to the assigned pick-up location for pick-up. The message mayfurther cause a display of an indication of an estimated walkingdistance from the starting point to the assigned pick-up location. Inaddition, the message may include an estimated walking distance from theassigned drop-off location to the desired destination. The assigneddrop-off location may be a location close to the desired destination,within the maximum walking distance parameters set by the first user.For example, the drop-off location may be at a location half a blockaway or further from the desired destination, and may be along a mainstreet where the vehicle may easily locate and access. For anotherexample, the drop-off location may be determined based on a routetowards the next pick-up location, such that the vehicle may easilydrop-off the first user on its way to the next pick-up location, therebyavoiding an extra detour.

In another embodiment, the message may include one or more proposalsassociated with different vehicles. Each proposal may includeinformation about the proposed pick-up location. The information aboutthe proposed pick-up location may include the distance from the user tothe proposed pick-up location. Each proposal may include a price of theride associated with the type of the ride, and an estimation of apick-up time. The estimate may be presented as a range. In one example,each proposal may include different pick-up locations, different prices,and/or different estimations of a pick-up time. According to thisembodiment, step 415 may also include receiving a proposal selectionreflective of a selected pick-up vehicle and sending an addition messagethat includes information about the selected vehicle, and the driverassociated with the vehicle. For example, the vehicle information mayinclude the license plate number, brand, color, and/or model of thevehicle. The driver information may include a name, nickname, profilephoto, ratings, number of previous rides, and/or contact information ofthe driver. The message may further include a contact option allowingthe user to contact the driver, for example, a “contact the driver”button, which the user may select to initiate a communication sessionwith the driver.

At step 417, ridesharing management server 150 may guide the assignedvehicle to the first pick-up location for picking up the first user. Forexample, ridesharing management server 150 may transmit directioninformation to the driver device associated with the assigned vehicle,for example, driver device 120D or driving-control device 120F. In someembodiments, a navigation component of the driver device, or thedriving-control device may perform the step of guiding the vehicle tothe first pick-up location. Correspondingly, ridesharing managementserver 150, or a navigation component of the user device 120A, may guidethe user to the first pick-up location, in cases where the pick-uplocation is an assigned pick-location different from the first startingpoint. For example, for autonomous vehicles used for ridesharingservices, such as autonomous vehicle 130F as shown in FIG. 1, thevehicle itself may be capable of using a variety of techniques to detectits surroundings, identify feasible paths, and navigate without directhuman input.

In some embodiments, once the vehicle is assigned to pick-up the user,ridesharing management server 150 may assign a communication channel forthe driver associated with the assigned vehicle to communicate with theuser, for example, a masked phone number. In some embodiments, a userinterface of a driver device, such as driver device 120D, may include anoption to send notification messages to the user, for example, apre-defined message button of “I'm here.” Once the vehicle arrives atthe pick-up location, the driver may click the message button to sendthe message to the user. This way, the driver may not need to dial outor type a message in order to notify the user of the vehicle's arrival,reducing driver distraction and associated safety hazards.

At step 419, ridesharing management server 150 may receive a second riderequest from a second user. In some embodiments, the second user requestmay be a street hailing request received directly by the vehicle whilethe first user is still inside, namely, before dropping off the firstuser. The vehicle may then undertake the second ride request, if thefirst user permits subsequent pick-ups. In some embodiments, the driverof the vehicle may input the second ride request information through adriver device, for example, driver device 120D associated with driver130D. The input may inform ridesharing management server 150 that thevehicle has undertaken a second ride request, or may further include thepick-up location and destination information of the second user.Ridesharing management server 150 may then accordingly determine whetherto assign additional pick-ups to the same vehicle, and may further senddirection information guiding the vehicle to the second user'sdestination.

In some embodiments, the second ride request may be received byridesharing management server 150 from a second wireless mobilecommunications device, for example, user device 120B associated withuser 130B as shown in FIG. 1. The second ride request may furtherinclude a second starting point, and a second desired destination.Ridesharing management server 150 may then assign a corresponding rideservice to an available vehicle, which may be the vehicle that haspicked up the first user, before dropping off the first user. Inprocessing the second ride request, the example process 420 as shown inFIG. 4B may be performed.

At step 422, ridesharing management server 150 may calculate a secondestimated pick-up time, for example, based on a second current locationof the vehicle and the second starting point. The second estimatedpick-up time may refer to an estimated time period before the vehiclearrives at a second pick-up location for picking up the second user. Thesecond pick-up location may be an assigned pick-up location differentfrom, but associated with, the second starting point. Assignment of thesecond pick-up location may include similar steps as described abovewith reference to FIG. 4A, details of which are not repeated herein.

At step 424, ridesharing management server 150 may send a second messageto the second wireless mobile communication device, which is user device120B in this example. The second message may be configured to cause anindication of the calculated second estimated pick-up time to appear ona display of the second wireless mobile communication device. Asdescribed above with reference to FIG. 4A, the message may appear indifferent formats, and may further cause a display of multiple proposalswith multiple options for the second pick-up location, walking distance,walking directions from the second starting point to the second pick-uplocation, etc., the details of which are not repeated herein.

In some embodiments, ridesharing management server 150 may set thesecond pick-up location at substantially the same location as the firstpick-up location, for example, half a block away, or 100 meters awayfrom the first pick-up location. This way, the vehicle may pick-up bothusers at about the same time at substantially the same location, furtherimproving service efficiency. In some embodiments, ridesharingmanagement server 150 may set the second pick-up location at asubstantially the same location as the first drop-off location, whereinthe vehicle may drop-off the first user, and pick-up the second user atabout the same time, without extra travelling. Further, in someembodiments, the second drop-off location may be set at substantiallythe same location as the first drop-off location, such that the vehiclemay drop-off multiple users at the same time.

In some embodiments, ridesharing management server 150 may set the firstpick-up location to substantially differ from the first starting point,and the second pick-up location to substantially differ from the secondstarting point, for example, to ensure both pick-up locations are alongthe same side of the same street where the vehicle may go through.Ridesharing management server 150 may then send respective directions tothe first user device and the second user device, to guide the users tothe respective pick-up locations.

In some embodiments, ridesharing management server 150 may set the firstpick-up location at substantially the same as the first starting point,and set the second pick-up location to substantially differ from thesecond starting point. For example, the selection of the pick-uplocations may be made such that the first pick-up location and thesecond pick-up location are close to one another, both pick-up locationsare along the same street, or the second pick-up location is close tothe first drop-off location. Ridesharing management server 150 may thensend respective directions to the first user device and the second userdevice, to guide the users to the respective pick-up locations.

At step 426, ridesharing management server 150 may guide the vehicle toa second pick-up location for picking up the second user. As describedabove with reference to FIG. 4A, this step may also be performed by anavigation component of the driver's device (e.g., driver device 120D ordriving-device 120F associated with autonomous vehicle 130F).

In some embodiments, ridesharing management server 150 may change thefirst drop-off location after receiving the second ride request, and thechange may be made without pre-approval of the first user. The firstdrop-off location refers to a location for dropping off the first user.As described above with reference to FIG. 4A, the first drop-offlocation may be the same as the first desired destination, or at alocation different from the first desired destination.

For example, the second pick-up location may be set at a location closeto the first desired destination, included in the first ride request.When assigning the second ride request to the vehicle, ridesharingmanagement server 150 may change the first drop-off location to alocation closer to or at the first desired destination, thus reducingthe walking distance for the first user to arrive at his desireddestination. For another example, the first drop-off location may bechanged to a location where the first user does not need to cross thestreet to arrive at his desired destination, without causing orincreasing detour for the vehicle to arrive at the second pick-uplocation.

In some embodiments, ridesharing management system 100 may subsequentlyreceive a plurality of subsequent ride requests. These additional riderequests may either be received by ridesharing management server 150 andassigned to the vehicles, or received by the vehicles in the form ofstreet hailing. Steps described above with reference to FIGS. 4A and 4Bmay similarly be used to process the third ride request.

For example, ridesharing management server 150 may receive a third riderequest from a third user device, for example, user device 120Cassociated with user 130C, as shown in FIG. 1. Ridesharing managementserver 150 may process the request and assign the request to the vehiclewhile at least one of a first user and a second user is still in thevehicle. The third ride request may further include a third startingpoint and a third desired destination. Ridesharing management server 150may calculate a third estimated pick-up time, and send a confirmation toa user's device e.g., user device 120C). Ridesharing management server150 may transmit direction and route information to the driver's deviceassociated with the vehicle (e.g., driver device 120D as shown in FIG.1), to guide the vehicle to pick-up and drop-off user 130C.

As described above with reference to FIGS. 4A and 4B, processing ofsubsequent ride requests may take into account of the ride serviceparameters set by the users whose requests have previously been receivedand assigned. For example, if both the first user and the second userare still in the vehicle, and one of them has set a maximum delay ofarrival, ridesharing management server 150 may not assign the thirdrequest to the same vehicle if such assignment would cause a delaylonger than the set value. For example, if the first user has set amaximum delay of arrival of 10 minutes, ridesharing management server150 may calculate an estimated time period it takes for the vehicle topick-up (and/or drop-off) the third user before dropping off the firstuser. If the estimated time would cause a total delay of arrival for thefirst user to exceed 10 minutes, ridesharing management server 150 maytherefore assign the third ride request to another vehicle. For anotherexample, if the second user has set a maximum number of one co-rider andthe second user will be dropped off earlier than the first user,ridesharing management server 150 may not assign to the same vehicle, assuch assignment may cause violation of the parameter (maximum number ofone co-rider) set by the second user.

FIG. 5 is a diagram of three example timelines showing ridesharingarrangements, in accordance with some embodiments of the presentdisclosure. As shown in example timelines 510, 520, and 530, for aparticular assigned vehicle undertaking a first ride request from afirst user and a second ride request from a second user, the order ofpick-ups and drop-offs for the second user may vary. For example,ridesharing management server 150 may receive a plurality of riderequests, design an optimal path and pick-up/drop-off order for aparticular assigned vehicle undertaking multiple requests, and assignadditional pick-ups as the vehicle completes a part of or all of theride requests. For example, as shown in example timeline 510, a vehiclemay receive a second ride request after picking up the first user, anddrop-off the first user before dropping off the second user. Acorresponding shared ride portion may be the portion of ride between thepick-up of the second user and drop-off of the first user. As shown inexample timeline 520, the vehicle may receive a second ride requestafter picking up the first user, and drop-off the second user beforedropping off the first user. A corresponding shared ride portion may bethe portion of ride between the pick-up of the second user and drop-offthe second user. As another example, as shown in example timeline 530,the vehicle may receive the first ride request and the second riderequest before any pick-up. The vehicle may then pick-up the second userbefore picking up the first user, and drop-off the second user beforedropping off the first user. A corresponding shared ride portion may bethe portion of ride between pick-up of the first user and drop-off ofthe second user. Depending on the order of pick-ups and drop-offs, theridesharing management server may then determine a corresponding sharedride portion, and calculate ride fare for each user based on, forexample, the shared portion, solo portion of each user, and/or otherfactors such as the ride service parameters set by each user.

Under-Utilization of Vehicle Capacity

Embodiments of the present disclosure may allow for the implementationof capacity blocks on rideshare vehicles. For example, the capacityblocks may ensure that the full capacity of the rideshare vehicles isnot used in regular operation. This may enhance the experience of userswho might otherwise feel cramped in vehicles at or near capacity.Indeed, some embodiments may implement the threshold block across afleet of ridesharing vehicles (e.g., by applying a threshold block toeach vehicle in the fleet, whether the same threshold or differentthresholds and/or by applying an aggregate threshold block to one ormore parts of the fleet).

In addition, the capacity block may be adjusted based on tracking ofpassengers' physical conditions capable of impacting capacity of aridesharing vehicle, tracking of passengers' luggage capable ofimpacting capacity of a ridesharing vehicle, or the like. Additionallyof alternatively, the capacity block may be overridden in particularcircumstances (e.g., inclement weather, special events, etc.). Suchdynamic reassessment of the capacity block may increase the efficiencyof a fleet of rideshare vehicles on the whole.

FIG. 6 depicts an example of a memory module 600 for under-utilizingvehicle capacity. Although depicted as a single memory in FIG. 6, memory600 may comprise one or more non-volatile (e.g., hard disk drive, flashmemory, etc.) and/or volatile (e.g., RAM or the like) memories. In someembodiments, memory 600 may be included in ridesharing management server150. For example, memory 600 may comprise, at least in part, a portionof memory 320.

As depicted in FIG. 6, memory 600 may include assignment module 610.Assignment module 610 may receive requests for shared rides from aplurality of users. For example, assignment module 610 may receive therequests using a communications interface. The communications interfacemay comprise, for example, one or more network interface controllers(NICs). These one or more NICs may communicate over one or more computernetworks, such as the Internet, a local area network (LAN), or the like.

Assignment module 610 may further assign the users to rideshare vehiclesin a fleet. For example, assignment module 610 may assign a first userto a first rideshare vehicle. In addition, assignment module 610 mayassign a second user to the first rideshare vehicle. For example,assignment module 610 may combine the first user and the second userbased on the closeness of a pick-up location of the first user to apick-up location and/or a destination of the second user, the closenessof a destination of the first user to the pick-up location and/or thedestination of the second user, overlap between a first predicted routefrom the pick-up location of the first user to the destination of thefirst user and a second predicted route from the pick-up location of thesecond user to the destination of the second user, or the like. Thepredicted routes may be calculated using one or more maps, optionally incombination with traffic information. The one or more maps may beretrieved from one or more memories and/or using the communicationsinterface. Similarly, the traffic information may be retrieved from oneor more memories and/or using the communications interface.

As further depicted in FIG. 6, memory 600 may include capacity trackingmodule 620. Capacity tracking module 620 may track a current utilizedcapacity in the rideshare fleet. For example, capacity tracking module620 may track the current utilized capacity of each specific ridesharingvehicle in the fleet. For example, capacity tracking module 620 maytrack capacity using assignments from assignment module 610.Additionally or alternatively, capacity tracking module 620 may trackcapacity when users are picked up by rideshare vehicles, e.g., usingsignals received from one or more devices (such as mobile communicationsdevice 200) associated with drivers of the rideshare vehicles and/orsignals received from one or more devices (such as mobile communicationsdevice 200) associated with the users.

In some embodiments, capacity tracking module 620 may account for otherfactors that impact capacity. For example, capacity tracking module 620may track passengers' physical condition capable of impacting capacityof a ridesharing vehicle (e.g., based on signals from the one or moredevices associated with the users and/or from the one or more devicesassociated with the drivers indicating whether a passenger has awheelchair, crutches, or the like). In another example, capacitytracking module 620 may track passengers' luggage capable of impactingcapacity of a ridesharing vehicle (e.g., based on signals from the oneor more devices associated with the users and/or from the one or moredevices associated with the drivers indicating amount and/or size ofluggage, or the like).

As depicted in FIG. 6, memory 600 may include a threshold block module630. Threshold block module 630 may implement a threshold block when aridesharing vehicle's current utilized capacity is above a threshold.For example, threshold block module 630 may receive the current utilizedcapacity from capacity tracking module 620. In some embodiments, thethreshold may be less than the ridesharing vehicle's passenger-capacity.For example, the threshold may be at least 10%, at least 15%, at least20%, at least 25%, or the like of the specific vehicle's capacity. In asimilar example, the threshold may be one seat less than the specificvehicle's capacity, two seats less, three seats less, or the like. Thethreshold. block may be implemented, for example, by sending a blocksignal to assignment module 610 to prevent assignment of additionalusers to the ridesharing vehicle.

In some embodiments, threshold block module 630 may determine a valuefor the threshold. For example, threshold block module 630 may accessstored information about the ridesharing vehicle to determine the value.The stored information may be in memory 600 and/or in one or moreadditional memories. Additionally or alternatively, the storedinformation may be received over the communications interface. Incertain aspects, the stored information may include a model of thevehicle, a make of the vehicle, a year of the vehicle, one or morepassengers' reviews of the vehicle, or the like.

In some embodiments, threshold block module 630 may override thethreshold. For example, threshold block module 630 may override thethreshold block in response to a received indication of an inclementweather condition, such as rain, snow, hail, or the like. In such anexample, the indication may be received from one or more memories and/orusing the communications interface. In another example, threshold blockmodule 630 may override the threshold block override in response to areceived indication of a special event condition, such as a sportingevent, a festival, a marathon, or the like. In such an example, theindication may be received from one or more memories and/or using thecommunications interface. In yet another example, threshold block module630 may override the threshold block when an estimated time in which theridesharing vehicle's utilized capacity is above the threshold is lessthan a predefined period of time, such as 1 minute, 3 minutes, 5minutes, 10 minutes, or the like. The predefined period of time may befixed or may be dynamic (e.g., determined based on stored informationabout the ridesharing vehicle). In a fourth example, threshold blockmodule 630 may override the threshold block in response to a receivedindication of an unscheduled-user condition (e.g., an indication thatthree passengers entered to the van when only one passenger scheduledthe ride). In such an example, the indication may be received from oneor more devices (such as mobile communications device 200) associatedwith the drivers and/or signals received from one or more devices (suchas mobile communications device 200) associated with the users.

Memory 600 may further include a database access module 640, and mayalso include database(s) 650. Database access module 640 may includesoftware instructions executable to interact with database(s) 650, tostore and/or retrieve information (e.g., information about theridesharing vehicle as described above, weather information, trafficinformation, one or more maps, or the like).

FIG. 7 is a diagram of example timelines showing the use of thresholdblocks in a rideshare fleet, in accordance with some embodiments of thepresent disclosure. As shown in example timeline 710, for a particularrideshare vehicle, ridesharing management server 150 may receive a firstrequest and a second request and assign both to the particular ridesharevehicle. In example timeline 710, ridesharing management server 150 mayimplement a threshold block when the capacity of the particularrideshare vehicle reaches 2. Accordingly, in example timeline 710, athird request is assigned to another rideshare vehicle on account of thethreshold block. Although depicted as tracking the capacity uponassignment of the requests, ridesharing management server 150 mayadditionally or alternatively track the capacity upon pick-up of theusers.

As shown in example timeline 720, for a particular rideshare vehicle,ridesharing management server 150 may receive an Nth request when theparticular rideshare vehicle is at capacity 1 and assign the Nth requestto the particular rideshare vehicle. In example timeline 720,ridesharing management server 150 may implement a threshold block afterassigning the Nth request (i.e., when the capacity of the particularrideshare vehicle reaches 2). Accordingly, in example timeline 720, the(N+1)th request is assigned to another rideshare vehicle on account ofthe threshold block. When the Nth user is dropped off, the capacity mayreturn to 1 and, accordingly, the (N+2)th request is assigned to theparticular rideshare vehicle. Similar to timeline 710, although depictedas tracking the capacity upon assignment of the requests in timeline720, ridesharing management server 150 may additionally or alternativelytrack the capacity upon pick-up of the users.

As shown in example timeline 730, for a particular rideshare vehicle,ridesharing management server 150 may receive an Nth request when theparticular rideshare vehicle is at capacity 1 and assign the Nth requestto the particular rideshare vehicle. In addition, ridesharing managementserver 150 may receive an (N+1)th request when the particular ridesharevehicle is at capacity 2 and assign the (N+1)th request to theparticular rideshare vehicle. In example timeline 730, ridesharingmanagement server 150 may implement a threshold block after assigningthe (N+1)th request (i.e., when the capacity of the particular ridesharevehicle reaches 3). Accordingly, in example timeline 730, the (N+2)threquest is assigned to another rideshare vehicle on account of thethreshold block. When the (N+1)th user is dropped off, the capacity mayreturn to 2 and, accordingly, the (N+2)th request may be re-assigned tothe particular rideshare vehicle. Similar to timelines 710 and 720,although depicted as tracking the capacity upon assignment of therequests in timeline 730, ridesharing management server 150 mayadditionally or alternatively track the capacity upon pick-up of theusers.

As shown in example timeline 740, for a particular rideshare vehicle,ridesharing management server 150 may receive a first request and asecond request and assign both to the particular rideshare vehicle. Inexample timeline 710, the first user may have an additional rider, oneor more pieces of luggage, and/or a physical condition that uses 3 seatsof capacity rather than 1. Accordingly, because ridesharing managementserver 150 may implement a threshold block when the capacity of theparticular rideshare vehicle reaches 3, the third user is re-assigned toanother rideshare vehicle on account of the threshold block activatedupon pick-up of the first user.

Although the examples of FIG. 7 use a threshold block of 2, variousthresholds may be used, as explained above with regards to thresholdblock module 630. For example, the threshold may be at least 10%, atleast 15%, at least 20%, at least 25%, or the like of the specificvehicle's capacity. In a similar example, the threshold may be one seatless than the specific vehicle's capacity, two seats less, three seatsless, or the like.

FIG. 8 depicts example method 800 for managing a fleet of ridesharingvehicles. Method 800 may, for example, be implemented by ridesharingmanagement server 150 of FIG. 3.

At step 811, server 150 may assign, to ridesharing vehicles alreadytransporting users, additional users for simultaneous transportation inthe ridesharing vehicles. For example, as explained above with regardsto assignment module 610, server 150 may make assignments based on thecloseness of pick-up locations of the users and the additional users,the closeness of destinations of the users and the additional users, thecloseness of pick-up locations of the users to destinations of theadditional users (or vice versa), overlap between predicted routes frontthe pick-up locations of the users to the destinations of the additionalusers and predicted routes from the pick-up locations of the users tothe destinations of the additional users, or the like.

At step 813, server 150 may track a current utilized capacity of eachspecific ridesharing vehicle. For example, as explained above withrespect to capacity tracking module 620, server 150 may track thecurrent utilized capacity using the assignments. Additionally oralternatively, server 150 may track the current utilized capacity whenthe users and/or the additional users are picked up by ridesharevehicles, e.g., using signals received from one or more devices (such asmobile communications device 200) associated with a driver of thespecific ridesharing vehicle and/or signals received from one or moredevices (such as mobile communications device 200) associated with theusers and/or the additional users.

At step 815, server 150 may implement a threshold block that preventsassignment of additional users to a ridesharing vehicle when theridesharing vehicle's current utilized capacity is above a thresholdbeing less than the ridesharing vehicle's passenger-capacity. Forexample, server 150 may implement the threshold block to prevent atleast 10% (or at least 15%, at least 20%, at least 25%, or the like) ofthe specific vehicle's capacity from being utilized. For example, if thespecific vehicle is an eight-seat van, at least one seat or at least twoseats may remain empty.

In some embodiments, server 150 may implement the threshold block acrossa fleet of ridesharing vehicles. For example, server 150 may apply athreshold block to each rideshare vehicle in the fleet. Additionally oralternatively, server 150 may implement one or more threshold blocks toone or more groups of vehicles.

In some embodiments, server 150 may store information about theridesharing vehicle. For example, server 150 may store staticinformation such as a year of the vehicle (e.g., 1999, 2005, 2017,etc.), a make of the vehicle (e.g., GM, Honda, Hyundai, Lincoln, etc.)model of the vehicle (e.g., Camry, Malibu, etc.).

Additionally or alternatively, server 150 may store dynamic informationsuch as one or more reviews of the vehicle by passengers. For example,server 150 may receive reviews (such as a rating, like 4 out of 5 or“Good,” optionally coupled with comments from the user) from one or moredevices (such as mobile communications device 200) associated with theusers and/or the additional users. In such an example, server 150 maycouple with received reviews with a capacity associated with thereviews. For example, if a review is received from a user that rode inthe vehicle when the capacity of the vehicle was at 3, server 150 mayassociate the review with a capacity of 3. In an example where a userrode in a vehicle during different capacities (e.g., began the ride at acapacity of 2 and ended the ride at a capacity of 3), server 150 mayassociate with the review with an average of the different capacities, aminimum of the different capacities, a maximum of the differentcapacities, or the like.

Based on the stored information, server 150 may determine a value forthe threshold based on information stored in the memory, the value beingspecific to each ridesharing vehicle. For example, server 150 maydetermine a passenger-capacity of the specific ridesharing vehicle basedon the particular year, make, and/or model of the specific ridesharingvehicle. Server 150 may then determine a value for the threshold suchthat the determined value for a specific ridesharing vehicle is one seatless than the passenger-capacity of the specific ridesharing vehicle,the determined value for a specific ridesharing vehicle is two seatsless than the passenger-capacity of the specific ridesharing vehicle,the determined value for a specific ridesharing vehicle is three seatsless than the passenger-capacity of the specific ridesharing vehicle, orthe like. In a similar example, when a specific ridesharing vehicle hasmore than ten seats, the determined value for the specific ridesharingvehicle may be less than ten seats.

Additionally or alternatively, server 150 may determine a value for thethreshold based on the reviews. For example, server 150 may determinethe value based on the majority of reviews being above a score thresholdwhen the associated capacities are below the threshold and the majorityof reviews being below the score threshold when the associatedcapacities are above the threshold. In another example, server 150 maydetermine the value based on detected sentiment of comments includedwith the reviews. In such an example, server 150 may determine the valuefor the threshold based on a value of the associated capacities at whichthe detected sentiments changes from positive to negative or based on avalue of the associated capacities at which a negativity of the detectedsentiments exceeds a negativity threshold.

Method 800 may further include additional steps. For example, method 800may include overriding the threshold block in response to a receivedindication of an inclement weather condition. For example, server 150may receive an indication of rain, snow, hail, or other inclementweather conditions and override the threshold block in response. Such anindication may be retrieved from one or more memories and/or receivedusing the communications interface (e.g., from a weather server and/orweather update service using the Internet).

In another example, method 800 may include overriding the thresholdblock override in response to a received indication of a special eventcondition. For example, server 150 may receive an indication of asporting event, a holiday, a festival, or other special event andoverride the threshold block in response. Such an indication may beretrieved from one or more memories and/or received using thecommunications interface (e.g., from a global calendar, a local calendarof events, a sports calendar, a holiday database, or the like using theInternet).

In yet another example, method 800 may include overriding the thresholdblock when an estimated time in which the ridesharing vehicle's utilizedcapacity is above the threshold is less than a predefined period oftime. For example, server 150 may estimate the time based on an overlapbetween the routes of the users and the routes of the additional users.The predefined period of time may be, for example, 3 minutes, 5 minutes,10 minutes, or the like.

In a fourth example, method 800 may include overriding the thresholdblock in response to a received indication of an unscheduled-usercondition. For example, server 150 may receive an indication that morepassengers entered the vehicle than initially indicated when the ridewas scheduled (e.g., 3 passengers enter when only 1 passenger requesteda ride). Such an indication may be received from one or more devices(such as mobile communications device 200) associated with the users.

Method 800 may further include cancelling the assignment of a firstrideshare vehicle and re-assigning a second rideshare vehicle in orderto enable the first rideshare vehicle to pick-up a passenger notoriginally assigned to the first rideshare vehicle. For example, if morepassengers enter the first vehicle than initially indicated when theride was scheduled (e.g., 2 passengers enter when only 1 passengerrequested a ride), server 150 may cancel another assignment to the firstvehicle and re-assign that request to a second vehicle. In sonicembodiments, the cancellation and rescheduling may be performed any timethat more passengers enter than originally indicated. In otherembodiments, the cancellation and rescheduling may only be performedwhen the extra passengers would cause the threshold block to beexceeded. For example, if 2 passengers enter the first vehicle when only1 passenger requested a ride, and the other assignment to the firstvehicle is for 2 passengers, server 150 may only cancel and re-assignthe other assignment if the threshold block for the first vehicle isless than 4. In another example, if 3 passengers enter the first vehiclewhen only 2 passengers requested a ride, and the other assignment to thefirst vehicle is for 1 passenger, server 150 may only cancel andre-assign the other assignment if the threshold block for the firstvehicle is less than 4. The re-assignment may be communicated to one ormore devices (such as mobile communications device 200) associated withthe additional users.

Server 150 may also account for factors other than passenger count thatmay affect capacity. For example, server 150 may track passengers'luggage capable of impacting capacity of the ridesharing vehicle. Insuch an example, server 150 may receive an indication that a user hasone or more suitcases, a bicycle, a music instrument, or the like. Basedon this indication, server 150 may increase the tracked utilizedcapacity of the vehicle to account for the luggage or otherwise assignfewer passengers to the vehicle. Such an indication may be received fromone or more devices (such as mobile communications device 200)associated with the user. Additionally or alternatively, such anindication may be received from one or more devices (such as mobilecommunications device 200) associated with a driver of the vehicle(e.g., if the user failed to indicate s/he had any luggage whensubmitting a ride request). In such an embodiment, server 150 may cancelone or more additional assignments to the vehicle and re-assign a secondrideshare vehicle in order to enable the vehicle to pick-up the luggage.

Additionally or alternatively, server 150 may track a passenger'sphysical condition capable of impacting capacity of the ridesharingvehicle. For example, server 150 may track if the user has a wheelchair,a baby, crutches, injury, or the like, or is obese or has any otherphysical condition that requires additional space. In such an example,server 150 may receive an indication of the physical condition. Based onthis indication, server 150 may increase the tracked utilized capacityof the vehicle to account for the physical condition or otherwise assignfewer passengers to the vehicle. Such an indication may be retrievedfrom one or more memories (e.g., a user database storing informationassociated with user accounts including indications of physicalconditions) and/or received from one or more devices (such as mobilecommunications device 200) associated with the user. Additionally oralternatively, such an indication may be received from one or moredevices (such as mobile communications device 200) associated with adriver of the vehicle (e.g., if the user failed to indicate s/he had aphysical condition when registering for a user account and/or submittinga ride request). In such an embodiment, server 150 may cancel one ormore additional assignments to the vehicle and re-assign a secondrideshare vehicle in order to enable the vehicle to accommodate thephysical condition.

Dynamic Re-Assignment of Vehicles

Embodiments of the present disclosure may allow for the dynamicre-assignment of rideshare vehicles. For example, passenger assignmentsmay be changed between a time of initial assignment and a time ofpicking up the passenger. This may enhance the experience of users whena vehicle to which they are initially assigned is delayed, for example,on account of traffic, weather, wrong turns, or the like. In addition,the dynamic re-assignment may be used to allow the fleet of ridesharevehicles to handle urgent requests. For example, users having a medicalemergency, family emergency, running late for a flight, or the like, maybe prioritized to increase aggregate satisfaction across all users.

FIG. 9 depicts an example of a memory module 900 for dynamicre-assignment of rideshare vehicles. Although depicted as a singlememory in FIG. 9, memory 900 may comprise one or more non-volatile(e.g., hard disk drive, flash memory, etc.) and/or volatile (e.g., RAMor the like) memories. In some embodiments, memory 900 may be includedin ridesharing management server 150. For example, memory 900 maycomprise, at least in part, a portion of memory 320.

As depicted in FIG. 9, memory 900 may include location module 910.Location module 910 may determine pick-up locations for users assignedto ridesharing vehicles. For example, location module 910 may receivelocation information (e.g., using GPS) from a first plurality ofcommunication devices (such as mobile communications device 200)associated with a plurality of users. In such an example, the receivedlocation information may be included in ride requests as startingpoints.

Additionally, location module 910 may receive location information fronta second plurality of communication devices (such as mobilecommunications device 200) associated with a plurality of ridesharingvehicles. In such an embodiment, location module 910 may continuouslyreceive location information from the first and second pluralities ofcommunication devices. As used herein, “continuously” does notnecessarily mean without interruption but may refer to the receipt ofinformation in a discretized manner having spacings (and/orinterruptions) each below a threshold of time, such as 50 ms, 100 ms,500 msec, 1 sec, 5 sec, 10 sec, 30 sec, or the like.

Location module 910 may determine pick-up locations for a first group ofusers assigned to a first ridesharing vehicle. For example, locationmodule 910 may determine the pick-up locations based on one or moreoptimization models run on one or more predicted routes between startingpoints and destinations of the users. The one or more optimizationmodels may include a shortest distance optimization, a shortest traveltime optimization (e.g., accounting for speed limits, traffic, wrongturns, etc.), a combination of distance and travel time optimization, afuel efficiency optimization (e.g., based on known fuel ratings of theridesharing vehicle), an electric battery charge optimization, or thelike. For example, any solution to the P v. NP problem later derived mayalso be incorporated into the optimization models. For at least some ofthe first group of users, the determined pick-up locations may differfrom the starting points.

Additionally or alternatively, location module 910 may determinedrop-off locations for a first group of users assigned to a firstridesharing vehicle. For example, location module 910 may determine thedrop-off locations based on one or more optimization models run on oneor more predicted routes between starting points and destinations of theusers. The one or more optimization models may include a shortestdistance optimization, a shortest travel time optimization (e.g.,accounting for speed limits, traffic, wrong turns, etc.), a fuelefficiency optimization (e.g., based on known fuel ratings of theridesharing vehicle), or the like. For example, any solution to the P v.NP problem later derived may also be incorporated into the optimizationmodels. For at least some of the first group of users, the determineddrop-off locations may differ from the destinations.

The pick-up locations and/or drop-off locations may be changed dependingon cancellations and re-assignments performed by assignment module 920.For example, location module 910 may change at least one drop-offlocation of at least one second user in a second ridesharing vehicleafter assignment of the second ridesharing vehicle to a first user. In asimilar example, location module 910 may change a pick-up location ofthe first user after cancellation of an assignment of a firstridesharing vehicle to the first user and/or after re-assignment of thesecond ridesharing vehicle to the first user.

In some embodiments, location module 910 may also send data to at leastsome of the first group of users to guide each user to a respectivepick-up location different from a corresponding starting point of eachsaid user. For example, location module 910 may send GPS coordinates ofthe pick-up locations, physical addresses of the pick-up locations, orthe like to devices of the first plurality of communication devices(such as mobile communications device 200) associated with the at leastsome of the first group of users. Each device may use receivedcoordinates, a received address, or the like to route (e.g., viawalking) the associated user from a current location of the device tothe pick-up location. In another example, location module 910 maydetermine routes (e.g., via walking) from current locations receivedfrom the devices to the pick-up locations and send the route to thedevices. Accordingly, location module 910 may send to the at least someof the first group of users walking directions to the respective pick-uplocations.

Additionally or alternatively, location module 910 may send to the atleast some of the first group of users at least one of a location and anaddress of the respective pick-up locations. For example, locationmodule 910 may send GPS coordinates of the respective pick-up locations,physical addresses of the pick-up locations, or the like to devices ofthe first plurality of communication devices (such as mobilecommunications device 200) associated with the at least some of thefirst group of users. Guiding the at least some of the first group ofusers (e.g., using routes and/or walking directions as described above)may be performed by the devices.

As further depicted in FIG. 9, memory 900 may include assignment module920. Assignment module 920 may receive ride requests from a firstplurality of communication devices (such as mobile communications device200) associated with a plurality of users. For example, assignmentmodule 920 may receive the requests using a communications interface.The communications interface may comprise, for example, one or morenetwork interface controllers (NICs). These one or more NICs maycommunicate over one or more computer networks, such as the Internet, alocal area network (LAN), or the like.

Assignment module 920 may further assign the rideshare vehicles in afleet to pick-up a plurality of users. For example, assignment module920 may assign a first ridesharing vehicle to pick-up a first group ofthe plurality of users. For example, assignment module 920 may combineusers to form the first group based on the closeness of the pick-uplocation of one user in the first group to a pick-up location and/or adestination of another user in the first group, the closeness of adestination of the user in the first group to the pick-up locationand/or the destination of the other user in the first group, overlapbetween a first predicted route from the pick-up location of the user tothe destination of the user and a second predicted route from thepick-up location of the other user to the destination of the other user,or the like. The predicted routes may be calculated using one or moremaps, optionally in combination with traffic information. The one ormore maps may be retrieved from one or more memories and/or using thecommunications interface. Similarly, the traffic information may beretrieved from one or more memories and/or using the communicationsinterface.

In some embodiments, assignment module 920 may cooperate with locationmodule 910 to perform dynamic re-assignment. For example, prior to afirst user arriving at a first pick-up location, assignment module 920may cancel the assignment of a first ridesharing vehicle to the firstuser while maintaining the assignment of the first ridesharing vehicleto others of the first group of users. Additionally or alternatively,assignment module 920 may cooperate with prediction module 930 toperform dynamic re-assignment. For example, assignment module 920 mayre-assign the first user to a second ridesharing vehicle, e.g., when apredicted passing time when a second ridesharing vehicle may pass thefirst pick-up location is after a predicted arrival time when the firstuser will arrive at the first pick-up location. In some embodiments, thesecond ridesharing vehicle may be carrying at least one second userwhile being assigned to the first user. For example, assignment module920 may assign to the second ridesharing vehicle (e.g., a van) alreadytransporting at least four second users for simultaneous transportationwith the first user. In another example, assignment module 920 mayassign to the second ridesharing vehicle (e.g., a taxi) alreadytransporting one or two second users for simultaneous transportationwith the first user.

The re-assignment may be performed similar to the initial assignment.For example, assignment module 920 may assign the first user to thesecond ridesharing vehicle based on a current location of the secondridesharing vehicle and a desired destination of the at least one seconduser. Additionally or alternatively, assignment module 920 may assignthe first user to the second ridesharing vehicle based on an overlapbetween a current route of the second ridesharing vehicle and apredicted route from the first pick-up location to the destination ofthe first user, or the like.

Additional dynamic re-assignments may be performed by assignment module920. For example, assignment module 920 may cancel the assignment of thefirst rideshare vehicle when an estimated arrival time of the firstridesharing vehicle is before an estimated arrival time of the firstuser. In certain aspects, assignment module 920 may cancel theassignment of the first rideshare vehicle when the estimated arrivallime of the first ridesharing vehicle is more than a predeterminedperiod of time (e.g., 0.5 minutes, 1 minute, 2 minutes, 3 minutes, 5minutes, or the like) before the estimated arrival time of the firstuser. In another example, assignment module 920 may cancel theassignment of the first rideshare vehicle when a delay in an arrival ofthe first ridesharing vehicle at the first pick-up location ispredicted. In certain aspects, assignment module 920 may cancel theassignment when the predicted delay is more than a predetermined periodof time (e.g., 5 minutes, 10 minutes, 15 minutes, or the like) ascompared to an original estimated arrival time of the first ridesharingvehicle at the first pick-up location, and the second ridesharingvehicle that may be reassigned with the first user is predicted to passfirst pick-up location earlier than first ridesharing vehicle.

As explained above with respect to FIG. 6, assignment module 920 maycancel the assignment of the first rideshare vehicle and re-assign thesecond rideshare vehicle to enable the first rideshare vehicle topick-up a passenger not originally assigned to the first ridesharevehicle (e.g., 4 passengers enter when only 2 passengers requested aride). For example, if the first rideshare vehicle has more passengersboard than were initially requested prior to picking up the first user,the second rideshare vehicle may be re-assigned to the first user. Incertain aspects, the second rideshare vehicle may be re-assigned only ifthe total passengers in the first rideshare vehicle exceed a threshold(e.g., 2 passengers, 4 passengers, a threshold block as described above,etc.).

In general, assignment module 920 may re-assign the second ridesharevehicle in order to minimize a total waiting time of the plurality ofusers. For example, assignment module 920 may determine thatre-assigning the second rideshare vehicle to one or more users initiallyassigned to the first rideshare vehicle (such as the first user) resultsin a lower total waiting time (i.e., a total waiting time for each userassigned to the first rideshare vehicle and each user assigned to thesecond rideshare vehicle) and then perform the re-assignment. Thepredicted total waiting time may depend on routes between startinglocations of the users and pick-up locations of the users as well aspredicted arrival times for the first rideshare vehicle and/or thesecond rideshare vehicle at the pick-up locations.

Additionally or alternatively, assignment module 920 may re-assign thesecond rideshare vehicle in order to minimize a total travel time of theplurality of users. For example, assignment module 920 may determinethat re-assigning the second rideshare vehicle to one or more usersinitially assigned to the first rideshare vehicle (such as the firstuser) results in a lower total travel time (i.e., a total travel timefor each user assigned to the first rideshare vehicle and each userassigned to the second rideshare vehicle) and then perform there-assignment. The predicted total travel time may depend on routesbetween pick-up locations of the users and drop-off locations of theusers as well as predicted arrival times for the first rideshare vehicleand/or the second rideshare vehicle at the drop-off locations and maychange in real time due to wrong turns and/or changes in trafficconditions.

Any time the assignment of the first ridesharing, vehicle to the firstuser is cancelled, the route of the first ridesharing vehicle may beautomatically updated. For example, the first ridesharing vehicle may bere-routed to bypass the pick-up location of the first user and thereforereach another pick-up location or drop-off location at an earlier timeand/or after traversing a shorter distance. Assignment module 920 mayfurther guide the first ridesharing vehicle to the other pick-uplocation or drop-off location. For example, assignment module 920 maysend the updated route to one or more devices of the second plurality ofcommunication devices (such as mobile communications device 200)associated with the first ridesharing vehicle.

Similarly, any time the first user is re-assigned to the secondridesharing vehicle, the route of the second ridesharing vehicle may beautomatically updated. For example, the second ridesharing vehicle maybe re-routed to pass the pick-up location of the first user, optionallybefore another pick-up location or drop-off location of the at least onesecond user. Assignment module 920 may guide the second ridesharingvehicle to the first pick-up location. For example, assignment module920 may send a route (or updated route) to one or more devices of thesecond plurality of communication devices (such as mobile communicationsdevice 200) associated with the second ridesharing vehicle.

As further depicted in FIG. 9, memory 900 may include prediction module930. Prediction module 930 may use the location information from thefirst and second pluralities of communication devices to estimatearrival times at respective pick-up locations. For example, predictionmodule 930 may use information received from a first communicationsdevice (e.g., derived from a GPS of the first communications device) ofa first user to predict when the first user will arrive at the assignedfirst pick-up location. Additionally or alternatively, information usedfor predicting when the first user will arrive at the assigned firstpick-up location may be derived from the ride request (e.g., which mayinclude a current location of the first user). In another example,prediction module 930 may use information received from a secondcommunications device (e.g., derived from a GPS of the secondcommunications device) of the first ridesharing vehicle to predict whenthe first ridesharing vehicle will arrive at the assigned first pick-uplocation.

Similarly, prediction module 930 may use information received from asecond communications device (e.g., derived from a GPS of the secondcommunications device) of a second ridesharing vehicle to predict when asecond ridesharing vehicle may pass the first pick-up location.Prediction module 930 may then compare the predicted passing time of thesecond ridesharing vehicle with the arrival time of the first user.

Prediction module 930 may make additional or alternative comparisons.For example, prediction module 930 may compare a predicted passing timeof the first ridesharing vehicle with the arrival time of the first userand/or any other user. In another example, prediction module 930 maycompare a predicted passing time of a third ridesharing vehicle with thearrival lime of the first user and/or any other user.

In embodiments where location module 910 continuously receives locationinformation from the first and second pluralities of communicationdevices, prediction module 930 may use the continuously receivedlocation information to estimate arrival times at respective pick-uplocations, similar to the examples explained above. In such embodiments,prediction module 930 may additionally or alternatively use thecontinuously received location information to predict a delay in anarrival of the first ridesharing vehicle at the first pick-up location.For example, prediction module 930 may use weather, traffic information,and/or information about emergency (e.g., fire, police, medical, etc.)activity (e.g., received using the communications interface and/orretrieved from one or more memories) to predict the delay. Additionallyor alternatively, prediction module 930 may compare the continuouslyreceived location information with a predicted route to determine if anywrong turns, unexpected slow downs, wrong turns, or the like, cause thefirst ridesharing vehicle to be at a different portion of the route thanexpected. Additionally or alternatively, prediction module 930 mayreceive information from one or more second communication devicesregarding a malfunctioning of an associated ridesharing vehicle andpredict a delay therefrom. Any of the above examples may similarly beused to predict a delay in arrival of one or more users and/or one ormore additional ridesharing vehicles.

Memory 900 may further include a database access module 940, and mayalso include database(s) 950. Database access module 940 may includesoftware instructions executable to interact with database(s) 950, tostore and/or retrieve information (e.g., information used to perform anyof the predictions described above, weather information, trafficinformation, one or more maps, or the like).

FIG. 10A is a diagram of example timelines showing the use of dynamicre-assignment in a rideshare fleet, in accordance with some embodimentsof the present disclosure. As shown in example timeline 1010,ridesharing management server 150 may receive a first request from afirst user, a second request from a second user, and a third requestfrom a third user. Ridesharing management server 150 may assign thefirst request, the second request, and the third request to a firstridesharing vehicle. Accordingly, the first user, the second user, andthe third user may form a first group of users.

After assignment, ridesharing management server 150 may determine afirst pick-up location for the first user, a second pick-up location forthe second user, and a third pick-up location for the third user. For atleast one of the users, the corresponding pick-up location may bedifferent from a starting point included in the corresponding request.Additionally or alternatively, ridesharing management server 150 maydetermine a first drop-off location for the first user, a seconddrop-off location for the second user, and a third drop-off location forthe third user. For at least one of the users, the correspondingdrop-off location may be different from a desired destination includedin the corresponding request.

In example timeline 1010, ridesharing management server 150 may predictan arrival time for the first user at the first pick-up location, anarrival time for the second user at the second pick-up location, and anarrival time for the third user at the third pick-up location. Forexample, ridesharing management server 150 may use information receivedfrom a first communications device of the first user to predict thearrival time for the first user, may use information received from afirst communications device of the second user to predict the arrivaltime for the second user, and/or may use information received from afirst communications device of the third user to predict the arrivaltime for the third user.

As further shown in example timeline 1010, prior to the first userarriving at the first pick-up location, ridesharing management server150 may cancel the assignment of the first ridesharing vehicle to thefirst user while maintaining the assignment of the first ridesharingvehicle to others of the first group of users. Further, ridesharingmanagement server 150 may predict when a second ridesharing vehicle maypass the first pick-up location. For example, ridesharing managementserver 150 may use information received from a second communicationsdevice associated with the second ridesharing vehicle. In exampletimeline 1010, because the predicted passing time of the secondridesharing vehicle is after the predicted arrival time of the firstuser, ridesharing server 150 may re-assign the first user to the secondridesharing vehicle.

As shown in example timeline 1020, ridesharing management server 150 mayreceive a first request from a first user and a second request from asecond user. Ridesharing management server 150 may assign the firstrequest and the second request to a first ridesharing vehicle.Accordingly, the first user and the second user may form a first groupof users.

After assignment, ridesharing management server 150 may determine afirst pick-up location for the first user and a second pick-up locationfor the second user. For at least one of the users, the correspondingpick-up location may be different from a starting point included in thecorresponding request. Additionally or alternatively, ridesharingmanagement server 150 may determine a first drop-off location for thefirst user and a second drop-off location for the second user. For atleast one of the users, the corresponding drop-off location may bedifferent from a desired destination included in the correspondingrequest.

In example timeline 1020, ridesharing management server 150 may predictan arrival time for the first user at the first pick-up location, anarrival time for the second user at the second pick-up location, and anarrival time of the first ridesharing vehicle at the first pick-uplocation and/or the second pick-up location. For example, ridesharingmanagement server 150 may use information received from a firstcommunications device of the first user to predict the arrival time forthe first user, may use information received from a first communicationsdevice of the second user to predict the arrival time for the seconduser, and/or may use information received from a second communicationsdevice associated with the first ridesharing vehicle.

Ridesharing management server 150 may continuously receive locationinformation to estimate arrival dines at respective pick-up locations.Accordingly, in example timeline 1020, ridesharing management server 150may calculate an updated arrival time of the first ridesharing vehicleat the first pick-up location and/or the second pick-up location.Although not depicted in FIG. ridesharing server 150 may additionally oralternatively calculate an updated arrival time for the first user atthe first pick-up location and/or an updated arrival time for the seconduser at the second pick-up location.

As further shown in example timeline 1020, ridesharing management server150 may cancel the assignment of the first rideshare vehicle when theestimated arrival time of the first ridesharing vehicle is before theestimate arrival time of the first user. Accordingly, ridesharingmanagement server 150 cancels the assignment when the updated arrivaltime of the first ridesharing vehicle at the first pick-up locationand/or the second pick-up location is before the arrival time for thefirst user at the first pick-up location. In some embodiments,ridesharing management server 150 may cancel the assignment of the firstrideshare vehicle when the estimated arrival time of the firstridesharing vehicle is more than a predetermined period of time (e.g.,0.5 minutes, 1 minute, 2 minutes, 3 minutes , 5 minutes, etc.) beforethe estimated arrival time of the first user.

Although not depicted in FIG. 10A ridesharing management server 150 mayfurther predict when a second ridesharing vehicle may pass the firstpick-up location, compare the predicted passing time of the secondridesharing vehicle with the arrival time of the first user, andre-assign the first user to the second ridesharing vehicle when thepredicted passing time is after the predicted arrival time.

As shown in example timeline 1030, ridesharing management server 150 mayreceive a first request from a first user and a second request from asecond user. Ridesharing management server 150 may assign the firstrequest and the second request to a first ridesharing vehicle.Accordingly, the first user and the second user may form a first groupof users.

After assignment, ridesharing management server 150 may determine afirst pick-up location for the first user and a second pick-up locationfor the second user. For at least one of the users, the correspondingpick-up location may be different from a starting point included in thecorresponding request. Additionally or alternatively, ridesharing,management server 150 may determine a first drop-off location for thefirst user and a second drop-off location for the second user. For atleast one of the users, the corresponding drop-off location may bedifferent from a desired destination included in the correspondingrequest.

In example timeline 1030, ridesharing management server 150 may predictan arrival time for the first user at the first pick-up location, anarrival time for the second user at the second pick-up location, and anarrival time of the first ridesharing vehicle at the first pick-uplocation and/or the second pick-up location. For example, ridesharingmanagement server 150 may use information received from a firstcommunications device of the first user to predict the arrival time forthe first user, may use information received from a first communicationsdevice of the second user to predict the arrival time for the seconduser, and/or may use information received from a second communicationsdevice associated with the first ridesharing vehicle.

Ridesharing management server 150 may continuously receive locationinformation to estimate arrival dines at respective pick-up locations.Accordingly, in example timeline 1030, ridesharing management server 150may calculate an updated arrival time of the first ridesharing vehicleat the first pick-up location and/or the second pick-up location.Although not depicted in FIG. 10A, ridesharing server 150 mayadditionally or alternatively calculate an updated arrival time for thefirst user at the first pick-up location and/or an updated arrival timefor the second user at the second pick-up location. In the example oftimeline 1030, ridesharing management server 150 has predicted a delayin an arrival of the first ridesharing vehicle at the first pick-uplocation and/or the second pick-up location. For example, the delay maybe due to traffic, weather, vehicle malfunction, police activity, wrongturns, or the like.

As further shown in example timeline 1030, ridesharing management server150 may cancel the assignment of the first rideshare vehicle because thedelay is predicted. Accordingly, ridesharing management server 150cancels the assignment when the updated arrival time of the firstridesharing vehicle is after the original estimated arrival time of thefirst ridesharing vehicle. In sonic embodiments, ridesharing managementserver 150 may cancel the assignment of the first rideshare vehicle whenthe estimated arrival time of the first ridesharing vehicle is more thana predetermined period of time (e.g., 5 minutes, 10 minutes, 15 minutes,etc.) later than the original estimated arrival time of the firstridesharing vehicle.

Although not depicted in FIG. 10A, ridesharing management server 150 mayfurther predict when a second ridesharing vehicle may pass the firstpick-up location, compare the predicted passing time of the secondridesharing vehicle with the arrival time of the first user, andre-assign the first user to the second ridesharing vehicle when thepredicted passing time is before the predicted arrival time. Inaddition, in some embodiments, ridesharing manager server may cancel theassignment of the first user to the first ridesharing vehicles only ifreassignment to the second ridesharing vehicle succeeds.

FIG. 10B is a diagram of additional example timelines showing the use ofdynamic re-assignment in a rideshare fleet, in accordance with someembodiments of the present disclosure. As shown in example timeline1040, ridesharing management server 150 may receive a first request froma first user, a second request from a second user, and a third requestfrom a third user. Ridesharing management server 150 may assign thefirst request, the second request, and the third request to a firstridesharing vehicle. Accordingly, the first user, the second user, andthe third user may form a first group of users.

After assignment, ridesharing management server 150 may determine afirst pick-up location for the first user, a second pick-up location forthe second user, and a third pick-up location for the third user. For atleast one of the users, the corresponding pick-up location may bedifferent from a starting point included in the corresponding request.Additionally or alternatively, ridesharing management server 150 maydetermine a first drop-off location for the first user, a seconddrop-off location for the second user, and a third drop-off location forthe third user. For at least one of the users, the correspondingdrop-off location may be different from a desired destination includedin the corresponding request.

In example timeline 1040, ridesharing management server 150 may predictan arrival time for the first user at the first pick-up location, anarrival time for the second user at the second pick-up location, and anarrival time for the third user at the third pick-up location. Forexample, ridesharing management server 150 may use information receivedfrom a first communications device of the first user to predict thearrival time for the first user, may use information received from afirst communications device of the second user to predict the arrivaltime for the second user, and or may use information received from afirst communications device of the third user to predict the arrivaltime for the third user.

As further shown in example timeline 1040, the first ridesharing vehiclemay pick-up the first user (e.g., from the first pick-up location).Thereafter, the first ridesharing vehicle may pick-up the third user(e.g., from the third pick-up location). In the example of timeline1040, although the third user has only requested a ride for a singlepassenger, two passengers actually board the first ridesharing vehicle.In one example, a second communications device associated with the firstridesharing vehicle may send a signal to ridesharing management server150 regarding the passenger not originally assigned to the firstrideshare vehicle. In response, ridesharing management server 150cancels the assignment of the first rideshare vehicle in order to enablethe first rideshare vehicle to pick-up a passenger not originallyassigned to the first rideshare vehicle. Although not depicted in FIG.109, ridesharing management server 150 may further re-assign a secondridesharing vehicle to the second user. For example, ridesharingmanagement server 150 may predict when the second ridesharing vehiclemay pass the second pick-up location and re-assign the secondridesharing vehicle when the predicted passing time is after thepredicted arrival time of the second user or after the planned pickuptime of the second user.

As shown in example timeline 1050, ridesharing management server 150 mayreceive a first request from a first user and a second request from asecond user. Ridesharing management server 150 may assign the firstrequest and the second request to a first ridesharing vehicle.Accordingly, the first user and the second user may form a first groupof users.

After assignment, ridesharing management server 150 may determine afirst pick-up location for the first user and a second pick-up locationfor the second user. For at least one of the users, the correspondingpick-up location may be different from a starting point included in thecorresponding request. Additionally or alternatively, ridesharingmanagement server 150 may determine a first drop-off location for thefirst user and a second drop-off location for the second user. For atleast one of the users, the corresponding drop-off location may bedifferent from a desired destination included in the correspondingrequest.

In example timeline 1050, ridesharing management server 150 may predictan arrival time for the first user at the first pick-up location, anarrival time for the second user at the second pick-up location, and anarrival time of the first ridesharing vehicle at the first pick-uplocation and/or the second pick-up location. For example, ridesharingmanagement server 150 may use information received from a firstcommunications device of the first user to predict the arrival time forthe first user, may use information received from a first communicationsdevice of the second user to predict the arrival time for the seconduser, and/or may use information received from a second communicationsdevice associated with the first ridesharing vehicle.

Ridesharing management server 150 may further determine a total waitingtime of the plurality of users. For example, each difference between thepredicted arrival time of a user and the predicted arrival time of thefirst ridesharing vehicle may be summed. In embodiments where thepredicted arrival time of the first ridesharing vehicle is before apredicted arrival time of one or more of the users, ridesharingmanagement server 150 may either subtract the difference between thearrival times from the total waiting time or may ignore the one or moreof the users in determining the total waiting time.

As further shown in example timeline 1050, ridesharing management server150 may cancel the assignment of the first rideshare vehicle to thesecond user and re-assign the second rideshare vehicle in order tominimize a total waiting time of the plurality of users. For example,ridesharing management server 150 may predict an arrival time of thesecond ridesharing vehicle at the second pick-up location and,therefrom, predict an updated total waiting time if the secondridesharing vehicle were to be re-assigned to the second user. If theupdated total waiting time is less than the initial total waiting time,ridesharing management server 150 may cancel the assignment of the firstrideshare vehicle to the second user and re-assign the second ridesharevehicle.

Additionally or alternatively, the second user may also be re-assignedto a new pick-up location during re-assignment. In such an embodiment,ridesharing management server 150 may predict an arrival time of thesecond ridesharing vehicle at the updated pick-up location and predictan arrival time of the second user at the updated pick-up location.Based on the arrival times at the updated pick-up location, ridesharingmanagement server 150 may predict an updated total waiting time if thesecond ridesharing vehicle were to be re-assigned to the second user. Ifthe updated total waiting time is less than the initial total waitingtime, ridesharing management server 150 may cancel the assignment of thefirst rideshare vehicle to the second user, re -assign the secondrideshare vehicle, and send the updated pick-up location to the seconduser.

Although not depicted in FIG. 10B, ridesharing management server 150 maydecline to re-assign the second ridesharing vehicle even if the updatedtotal waiting time is less than the initial total waiting time. Forexample, one or more thresholds (e.g., 10 minutes, 15 minutes, or thelike) may be applied to a predicted waiting time for an individual user.In this example, ridesharing management server 150 may decline tore-assign the second ridesharing vehicle if the re-assignment wouldresult in a predicted waiting time for a user exceeding the threshold.Accordingly, inconveniences to individual users may be capped in orderto encourage such users to become repeat riders and enjoy the advantagesof fleet-wide optimization on one or more future trips.

Any of the examples of FIGS. 10A and 10B may be combined. For example,the minimization of total wait time in example timeline 1050 may beapplied to any of the example timelines 1010, 1020, 1030, and/or 1040.In another example, the enablement of a rideshare vehicle to pick-up apassenger not originally assigned to the rideshare vehicle in exampletimeline 1040 may be applied to any of the example timelines 1010, 1020,1030, and/or 1050.

FIGS. 11A and 11B depict example method 1100 for managing a fleet ofridesharing vehicles. Method 1100 may, for example, be implemented byridesharing management server 150 of FIG.

At step 1107, server 150 may receive ride requests from a firstplurality of communication devices associated with a plurality of users.For example, server 150 may receive the ride requests using one or morecommunications interfaces (such as communications interface 360). Insome embodiments, each ride request includes a starting point and adesired destination corresponding to each of the plurality of users. Thestarting point may be included as GPS coordinates, a physical address,or the like. Similarly, the desired destination may be included as GPScoordinates, a physical address, or the like.

At step 1109, server 150 may receive location information from a secondplurality of communication devices associated with a plurality ofridesharing vehicles. For example, server 150 may receive the riderequests using one or more communications interfaces (such ascommunications interface 360). In some embodiments, the locationinformation may include information derived from one or more GPS devicesof the second communications devices.

At step 1111, server 150 may assign a first ridesharing vehicle topick-up a first group of the plurality of users. For example, the firstgroup may include a first user, a second user, a third user, etc. Someusers may be included in the same request (e.g., if a first user and asecond user are included in a first request). As explained above withregards to assignment module 920, server 150 may assemble the firstgroup of the plurality of users based on the closeness of startingpoints of the assembled users, the closeness of the desired destinationsof the assembled users, the closeness of the starting points of some ofthe first group to desired destinations of others of the first group,overlap between predicted routes from the starting points to the desireddestinations of some of first group and predicted routes from thestarting points to the desired destinations of others of the firstgroup, or the like.

At step 1113, server 150 may determine pick-up locations for the firstgroup of users. For example, sever 150 may determine a pick-up locationfor each user in the first group of users at which the correspondinguser will meet the first ridesharing vehicle. For at least some of thefirst group of users, the determined pick-up locations may differ fromthe starting points.

At step 1115, server 150 may send data to the at least some of the firstgroup of users to guide each user to a respective pick-up locationdifferent from a corresponding starting point of each said user. Forexample, server 150 may send to at least some of the first group ofusers at least one of a location and an address of the respectivepick-up locations. In this example, server 150 may send the location(e.g., GPS coordinates) and/or the address to a corresponding firstcommunications device associated with the corresponding user.Additionally or alternatively, server 150 may send to at least some ofthe first group of users walking directions to the respective pick-uplocations.

At step 1117, server 150 may use information received from a firstcommunications device of a first user to predict when the first userwill arrive the assigned first pick-up location. For example, theinformation used for predicting when the first user will arrive at theassigned first pick-up location may be derived from the ride request.Additionally or alternatively, the information used for predicting whenthe first user will arrive at the assigned first pick-up location isderived from a GPS of the first communications device.

At step 1119, prior to the first user arriving at a first pick-uplocation, server 150 may cancel the assignment of the first ridesharingvehicle to the first user while maintaining the assignment of the firstridesharing vehicle to others of the first group of users. For example,server 150 may send the cancellation to a second communications deviceassociated with the first ridesharing vehicle and/or to the firstcommunications device associated with the first user.

Additionally or alternatively, server 150 may cancel the assignment ofthe first rideshare vehicle when an estimated arrival time of the firstridesharing vehicle is before the estimate arrival time of the firstuser. For example, as explained above with respect to prediction module930, server 150 may estimate an arrival time for the first ridesharingvehicle in addition to predicting the arrival time for the first user instep 1117. Optionally, as explained above with respect to assignmentmodule 920, server 150 may cancel the assignment when an estimatedarrival time of the first ridesharing vehicle is more than apredetermined period of time before the estimate arrival time of thefirst user.

Server 150 may optionally automatically update a route of the firstridesharing vehicle after cancelling the assignment of the firstridesharing vehicle to the first user. For example, as explained abovewith respect to location module 910, the updated route may omit apick-up location and a drop-off location associated with the first user.

At step 1121, server 150 may predict when a second ridesharing vehiclemay pass the first pick-up location. For example, as explained abovewith respect to prediction module 930, server 150 may estimate anarrival time for the second ridesharing vehicle in addition topredicting the arrival time for the first user in step 1117.

At step 1123, server 150 may compare the predicted passing time of thesecond ridesharing vehicle with the arrival time of the first user. Forexample, server 150 may perform an absolute comparison (e.g., adifference of 2 minutes, a difference of 5 minutes, etc.), a relativecomparison (e.g., a difference of 10%, a difference of 20%, etc.), orthe like. In some embodiments, the second ridesharing vehicle may becarrying at least one second user (e.g., one second user, two secondusers, four second users, etc.) while being assigning to the first user.

At step 1125, server 150 may re-assign the first user to the secondridesharing vehicle when the predicted passing time is after thepredicted arrival time. Optionally, server 150 may re-assign the firstuser only when the predicted passing time is within one or morethresholds after the predicted arrival time. For example, server 150 mayre-assign the first user if the predicted passing time is less than 5minutes, 10 minutes, etc. after the predicted arrival time and/or mayre-assign the first user if the predicted passing time is more than 1minute, 2 minutes, etc. after the predicted arrival time. In someembodiments, server 150 may guide the second ridesharing vehicle to thefirst pick-up location. For example, as explained above with respect tolocation module 910, server 150 may send a location (e.g., UPScoordinates) and/or an address of the first pick-up location to a secondcommunications device associated with the second ridesharing vehicleand/or send driving directions to the first pick-up location to thesecond communications device.

Additionally or alternatively, server 150 may assign the first user tothe second ridesharing vehicle based on a current location of the secondridesharing vehicle and a desired destination of the at least one seconduser. For example, as explained above with regards to assignment module920, server 150 may assign the first user based on the closeness ofstarting points of the first user and the at least one second user, thecloseness of the desired destinations of the first user and the at leastone second user, the closeness of the starting point of the first userto desired destinations of the at least one second user (or vice versa),overlap between a predicted route from the starting point to the desireddestination of the first user and predicted routes from the startingpoints to the desired destinations of the at least one second user, orthe like.

Additionally or alternatively, server 150 may re-assign the secondrideshare vehicle in order to minimize a total waiting time of theplurality of users. For example, as explained above with regards toprediction module 930, server 150 may calculate an initial total waittime and predict an updated total wait time and perform the(cancellation and) re-assignment if the updated total wait time is lessthan the initial total wait time. Optionally, as explained above withregards to prediction module 930, server 150 may perform the(cancellation and) re-assignment only if the difference between theupdated total wait time and the initial total wait time is above athreshold (e.g., 2 minutes, 5 minutes, 10 minutes, etc.) and/or only ifa predicted wait time of the re-assigned user remains below a threshold(such as 10 minutes, 15 minutes, or the like).

Server 150 may optionally automatically update a route of the secondridesharing vehicle after the re-assigning of the first user. Forexample, as explained above with respect to location module 910, theupdated route may include a pick-up location and a drop-off locationassociated with the first user. Moreover, server 150 may optionallychange at least one drop-off location of the at least one second userafter assignment of the second ridesharing vehicle to the first user.Additionally or alternatively, server 150 may optionally change apick-up location of the first user after assignment of the secondridesharing vehicle to the first user.

Method 1100 may further include additional steps. For example, asexplained above with respect to location module 910, method 1100 mayinclude continuously receiving location information from the first andsecond pluralities of communication devices to estimate arrival times atrespective pick-up locations. In such embodiments, as explained abovewith respect to assignment module 920 and prediction module 930, server150 may cancel the assignment of the first rideshare vehicle when theestimated arrival time of the first ridesharing vehicle is before theestimate arrival time of the first user. Additionally or alternatively,in such embodiments, as explained above with respect to assignmentmodule 920 and prediction module 930, server 150 may predict a delay inan arrival of the first ridesharing vehicle at the first pick-uplocation and may cancel the assignment of the first rideshare vehiclewhen a delay is predicted. For example, server 150 may cancel theassignment of the first rideshare vehicle when the predicted delay inarrival of the first ridesharing vehicle at the first pick-up locationis more than a predetermined period of time compared to an originalestimated arrival time of the first ridesharing vehicle at the firstpick-up location.

In another example, method 1100 may further include (as an additionalstep or in combination with or as an alternatively to step 1119)cancelling the assignment of the first rideshare vehicle andre-assigning the second rideshare vehicle in order to enable the firstrideshare vehicle to pick-up a passenger not originally assigned to thefirst rideshare vehicle. For example, as explained above with respect toexample timeline 1040, one or more additional passengers may board thefirst ridesharing vehicle than initially requested or anticipated, andserver 150 may re -assign the first user to accommodate such additionalpassengers.

FIGS. 11C and 11D depict another example method 1150 for managing afleet of ridesharing vehicles. Method 1100 may, for example, beimplemented by ridesharing management server 150 of FIG. 3.

At step 1157, server 150 may receive ride requests from a firstplurality of communication devices associated with a plurality of users.For example, server 150 may receive the ride requests using one or morecommunications interfaces (such as communications interface 360). Insome embodiments, each ride request includes a starting point and adesired destination corresponding to each of the plurality of users. Thestarting point may be included as GPS coordinates, a physical address,or the like. Similarly, the desired destination may be included as GPScoordinates, a physical address, or the like.

At step 1159, server 150 may receive location information from a secondplurality of communication devices associated with a plurality ofridesharing vehicles. For example, server 150 may receive the riderequests using one or more communications interfaces (such ascommunications interface 360). In some embodiments, the locationinformation may include information derived from one or more UPS devicesof the second communications devices.

At step 1161, server 150 may assign a first ridesharing vehicle topick-up a group of the plurality of users. For example, the group mayinclude a first user, a second user, a third user, etc. Some users maybe included in the same request (e.g., if a first user and a second userare included in a first request). As explained above regardingassignment module 920, server 150 may assemble the group of theplurality of users based on the closeness of starting points of theassembled users, the closeness of the desired destinations of theassembled users, the closeness of the starting points of some of thegroup to desired destinations of others of the group, overlap betweenpredicted routes from the starting points to the desired destinations ofsome of group and predicted routes from the starting points to thedesired destinations of others of the group, or the like.

At step 1163, server 150 may determine pick-up locations for the groupof users. For example, sever 150 may determine a pick-up location foreach user in the group of users at which the corresponding user willmeet the first ridesharing vehicle. In some embodiments, the determinedpick-up locations may differ from the starting points.

At step 1165, server 150 may send data to the group of the plurality ofusers indicating appointed pick-up times at the determined pick-uplocations. For example, server 150 may send to the group of users atleast one of a location and an address of the respective pick-uplocations. In this example, server 150 may send the location (e.g., GPScoordinates) and/or the address to a corresponding first communicationsdevice associated with the corresponding user. Additionally oralternatively, server 150 may send to the group of users walkingdirections to the respective pick-up locations. Moreover, as explainedabove with respect to prediction module 930, server 150 may estimatearrival times for the first ridesharing vehicle at the determinedpick-up locations and/or arrival times for corresponding users atcorresponding pick-up locations. Based on predicted arrival times,server 150 may appoint corresponding pick-up times to users. Forexample, the pick-up times may correspond to predicted arrival times ofthe first ridesharing vehicle, to predicted arrival times of thecorresponding users, or any combination thereof (e.g., by selecting themaximum of two predicted arrival times). In some embodiments, thepick-up times may correspond to predicted arrival times with one or morebuffers added. For example, server 150 may add an absolute buffer, suchas one minute, two minutes, five minutes, or the like, and/or a relativebuffer, such as 5%, 10%, 15%, or the like, to a predicted arrival timeto determine a corresponding pick-up time.

At step 1167, server 150 may use information received from at least oneof the plurality of ridesharing vehicles to predict when the firstridesharing vehicle will arrive to a first pick-up location assigned toa first user. For example, as explained above with respect to predictionmodule 930, server 150 may estimate an arrival time for the firstridesharing vehicle. In some embodiments, the information used topredict when the first ridesharing vehicle will arrive at the firstpick-up location may include GPS data from the first ridesharing vehicleand/or real-time traffic updates from the plurality of ridesharingvehicles.

At step 1169, prior to a first pick-up time associated with the firstuser, server 150 may estimate that the first ridesharing vehicle isgoing to be late to the first pick-up location by more than a timethreshold. For example, as explained above with respect to predictionmodule 930, server 150 may estimate an arrival time for the first userin addition to predicting the arrival time for the first ridesharingvehicle in step 1169. Accordingly, server 150 may estimate latenessbased on a comparison of the estimated arrival time for the firstridesharing vehicle and the estimated arrival time for the first user.Additionally or alternatively, server 150 may estimate lateness based ona comparison of the estimated arrival time for the first ridesharingvehicle and the appointed pick-up time for the first user. In someembodiments, the time threshold may have a value between 2 minutes and20 minutes e.g., after the first pick-up time).

At step 1171, server 150 may identify a second ridesharing vehicle to beassigned to pick-up the first user. For example, server 150 may identifythe second ridesharing vehicle based on which vehicles in the pluralityof ridesharing vehicles have no current passengers and/or are near thefirst pick-up locations. Server 150 may use information from the secondplurality of communication devices associated with the plurality ofridesharing vehicles to perform the identification,

At step 1173, server 150 may cancel the assignment of the firstridesharing vehicle to the first user while maintaining the assignmentof the first ridesharing vehicle to others of the group of the pluralityof users. Server 150 may optionally automatically update a route of thefirst ridesharing vehicle after cancelling the assignment of the firstridesharing vehicle to the first user. For example, as explained abovewith respect to location module 910, the updated route may omit apick-up location and a drop-off location associated with the first user.

At step 1175, server 150 may assign the second ridesharing vehicle topick up the first user. Optionally, server 150 may determine that thesecond ridesharing vehicle can pick up the first user before the firstridesharing vehicle. For example, as explained above with respect toprediction module 930, server 150 may predict a passing time for thefirst ridesharing vehicle and a passing time the second ridesharingvehicle at the first pick-up location and compare the predicted passingtimes to make the determination.

Method 1150 may include additional steps. For example, method 1150 mayinclude determining that, by assigning the second ridesharing vehicle topick up the first user, a first time delay of at least one passengerriding in the first ridesharing vehicle is lower than a second timedelay of the at least one passenger when the first user is assigned tothe first ridesharing vehicle. For example, as explained above withrespect to prediction module 930, server 150 may predict the second timedelay (e.g., a delay in arrival of the first ridesharing vehicle at acorresponding pick-up location, a delay in arrival of the firstridesharing vehicle at a corresponding drop-off location, and/or a delayin the length of drive between the corresponding pick-up location andthe corresponding drop-off location) for at least one passenger (e.g.,not the first user) riding in (and/or assigned to) the first ridesharingvehicle. The time delay may be caused, for example, by the lateness ofthe first ridesharing vehicle to the first pick-up location (andcorresponding and/or cascading lateness to other pick-up locations).Moreover, as explained above with respect to prediction module 930,server 150 may predict the first time delay for the at least onepassenger based on a hypothesis that the first user is assigned to thesecond ridesharing vehicle rather than the first ridesharing vehicle.Accordingly, server 150 may assign the first use to the secondridesharing vehicle only if the first time delay is predicted to belower than the second time delay (i.e., that assignment of the firstuser to the second ridesharing vehicle will reduce a time delay for atleast one passenger riding in and/or assigned to the first ridesharingvehicle). In some embodiments, server 150 may perform the assignmentonly if the first time delay is higher than the second time delay by athreshold, e.g., six minutes, twelve minutes, or the like.

Method 1150 may optionally be implemented in combination with method1100. For example, server 150 may re-assign the first user to the secondridesharing vehicle when the predicted passing time is after thepredicted arrival time and when the first ridesharing vehicle is goingto be late to the first pick-up location by more than a time threshold.In other words, server 150 may combine methods 1100 and 1150 such thatsteps 1125 and 1175 are combined.

Sub-Optimization of Individual Routes

Embodiments of the present disclosure may allow for the sub-optimizationof individual routes within a ridesharing fleet. For example, individualroutes for one or more users may be sub-optimized in order to allow forgreater optimization of the fleet (or at least a portion of the fleet)as a whole. This may enhance the overall experience of users whileincurring insignificant costs to individual users. Users mayparticularly experience the effects of fleet-wide optimization if theyare repeat customers.

In some embodiments, the sub-optimization may be limited by one or moreconstraints. For example, an individual sub-optimization may be rejectedif it results in a user waiting more than 10 minutes, 15 minutes, or thelike to be picked up by a ridesharing vehicle, even if such asub-optimization would allow for greater optimization of the fleet as awhole. Such constraints balance the needs of individual users with thebenefits of fleet-wide optimization.

FIG. 12 depicts an example of a memory module 1200 for sub-optimizationof individual routes. Although depicted as a single memory in FIG. 12,memory 1200 may comprise one or more non-volatile (e.g., hard diskdrive, flash memory, etc.) and/or volatile (e.g., RAM or the like)memories. In some embodiments, memory 1200 may be included inridesharing management server 150. For example, memory 1200 maycomprise, at least in part, a portion of memory 320.

As depicted in FIG. 12, memory 1200 may include request module 1210.Request module 1210 may receive a first request for a shared ride from afirst user. For example, the first request may be received via acommunications interface, such as communications interface 360. Thecommunications interface may comprise, for example, one or more networkinterface controllers (NICs). These one or more NiCs may communicateover one or more computer networks, such as the Internet, a local areanetwork (LAN), or the like. In some embodiments, the first request mayinclude information related to a first pick-up location of the firstuser and a first desired destination of the first user. The informationrelated to the first pick-up location may include GPS coordinates, aphysical address, or the like of the first pick-up location. Similarly,the information related to the first desired destination may include GPScoordinates, a physical address, or the like of the first desireddestination. Additionally or alternatively, the information related tothe first pick-up location may include a current location of the firstuser (e.g., derived from a GPS device of a first communications deviceassociated with the first user) and/or a user-requested pick-uplocation. For example, the first user may request to be picked up at acertain location (e.g., certain GPS coordinates, a certain physicaladdress, or the like), e.g., by inputting the certain location into thefirst communications device associated with the first user. Optionally,the information related to the first pick-up location may also include arequested time for pick-up, e.g., based on input to the firstcommunications device associated with the first user.

Request module 1210 may further receive a second request for a sharedride from a second user. For example, the second request may be receivedvia the communications interface, such as communications interface 360In some embodiments, the second request may include information relatedto a second pick-up location of the second user and a second desireddestination of the second user. The information related to the secondpick-up location may include GPS coordinates, a physical address, or thelike of the second pick-up location. Similarly, the information relatedto the second desired destination may include GPS coordinates, aphysical address, or the like of the second desired destination.Additionally or alternatively, the information related to the secondpick-up location may include a current location of the second user(e.g., derived from a GPS device of a first communications deviceassociated with the second user) and/or a user-requested pick-uplocation. For example, the second user may request to be picked up at acertain location (e.g., certain GPS coordinates, a certain physicaladdress, or the like), e.g., by inputting the certain location into thefirst communications device associated with the first user. Optionally,the information related to the second pick-up location may also includea requested time for pick-up, e.g., based on input to the firstcommunications device associated with the second user.

Request module 1210 may further receive a third request for a sharedride from a third user. For example, the third request may be receivedvia the communications interface, such as communications interface 360.In some embodiments, the third request may include information relatedto a third pick-up location of the third user and a third desireddestination of the third user. The information related to the thirdpick-up location may include GPS coordinates, a physical address, or thelike of the third pick-up location. Similarly, the information relatedto the third desired destination may include GPS coordinates, a physicaladdress, or the like of the third desired destination. Additionally oralternatively, the information related to the third pick-up location mayinclude a current location of the third user (e.g., derived from a GPSdevice of a first communications device associated with the third user)and/or a user-requested pick-up location. For example, the third usermay request to be picked up at a certain location (e.g., certain GPScoordinates, a certain physical address, or the like), e.g., byinputting the certain location into the first communications deviceassociated with the third user. Optionally, the information related tothe third pick-up location may also include a requested time forpick-up, e.g., based on input to the first communications deviceassociated with the third user.

In some embodiments, request module 1210 may receive the requests forshared rides from a plurality of first mobile communications devices(such as mobile communications device 200) associated with the pluralityof users. As explained above, such first mobile communications devicemay send requests to request module 1210 via the communicationsinterface including information input into the mobile communicationsdevice by the associated user, information derived from a GPS device ofthe mobile communications device, or the like.

Additionally or alternatively, request module 1210 may receive from aplurality of second mobile communication devices associated with aplurality of ridesharing vehicles, information about a current locationof each of the second mobile communications devices. For example, thecurrent location may be derived from a location circuit within each ofthe second mobile devices. The plurality of second mobile communicationdevices may include a plurality of handheld devices (such as mobilecommunications device 200) associated with drivers of at least a part ofthe fleet of ridesharing vehicles and/or a plurality of transmitters(such as driving-control device 120F) embedded in autonomous vehiclesthat are a part of the fleet of ridesharing vehicles.

In some embodiments, request module 1210 (and/or route module 1220,described below) may continuously receive location information from theplurality of first mobile communications devices and/or the plurality ofsecond mobile communication devices. As used herein, “continuously” doesnot necessarily mean without interruption but may refer to the receiptof information in a discretized manner having spacings (and/orinterruptions) each below a threshold of time, such as 50 ms, 100 ms,500 msec, 1 sec, 5 sec, 10 sec, 30 sec, or the like.

Request module 1210 may further identify a first ridesharing vehicle anda second ridesharing vehicle that are currently without passengers. Forexample, request module 1210 may identify the vehicles using signalsreceived from associated second mobile communication devices. In such anexample, the second mobile communication devices may send an. Indicatorof how many passengers are in the associated vehicle based on input froma driver of the associated vehicle and/or based on output from anapplication (or other software module) on the second mobilecommunication device that tracks the number of passengers in theassociated vehicle. Additionally or alternatively, request module 1210may identify the vehicles based on centralized tracking of capacity atridesharing server 150 (e.g., as explained above with respect tocapacity tracking module 620).

In some embodiments, the third request may be received while both thefirst user and the second user are riding in the first ridesharingvehicle. In such an embodiment, request module 1210 may schedule pickingup of the third user before dropping off the first user. Examples ofthis embodiment are depicted in FIGS. 13E and 13F. Alternatively,request module 1210 may schedule picking up the third user afterdropping off the first user and before dropping off the second user.Examples of this embodiment are depicted in FIGS. 13C and 13D.

As further depicted in FIG. 12, memory 1200 may include route module1220. Route module 1220 may assign a first user and a second user to afirst ridesharing vehicle. For example, mute module 1220 may assign theusers to the first ridesharing vehicle when request module 1210identifies the first ridesharing vehicle as currently withoutpassengers.

Additional or alternative factors may be considered by route module 1220when assignment the users to the first ridesharing vehicle. For example,route module 1220 may assign the first user and the second user to thefirst ridesharing vehicle based on the closeness of a starting pointand/or the pick-up location of the first user to a starting point, thepick-up location, the desired destination, and/or a drop-off location ofthe second user, the closeness of the desired destination and/or adrop-off location of the first user to a starting point, the pick-uplocation, the desired destination, and/or a drop-off location of thesecond user, overlap between a first predicted route from the pick-uplocation of the first user to the desired destination of the first userand a second predicted route from the pick-up location of the seconduser to the desired destination of the second user, or the like. Thepredicted routes may be calculated using one or more maps, optionally incombination with traffic information. The one or more maps may beretrieved from one or more memories and/or using the communicationsinterface. Similarly, the traffic information may be retrieved from oneor more memories and/or using the communications interface.

Route module 1220 may also generate a route to the first ridesharingvehicle for picking up and dropping off each of the first user and thesecond user. For example, route module 1220 may generate the route basedon one or more optimization models run on the pick-up locations of thefirst user and the second user as well as the desired destinations ofthe first user and the second user. One or more maps (e.g., retrievedfrom one or more memories and/or using the communications interface),optionally with traffic and/or weather information (e.g., retrieved fromone or more memories and/or using the communications interface) may alsobe fed into the optimization model(s). The one or more optimizationmodels may include a shortest distance optimization, a shortest traveltime optimization (e.g., accounting for speed limits, traffic, etc.), afuel efficiency optimization (e.g., based on known fuel ratings of theridesharing vehicle), or the like. For example, any solution to the P v.NP problem later derived may also be incorporated into the optimizationmodels.

In some embodiments, route module 1220 may determine the pick-uplocations and/or drop-off locations for at least one of (or each of) thefirst, second, and third users. For example, route module 1220 maydetermine the pick-up location(s) and/or the drop-off location(s) basedon one or more optimization models run on one or more predicted routesbetween starting points and destinations of the users. The one or moreoptimization models may include a shortest distance optimization, ashortest travel time optimization (e.g., accounting for speed limits,traffic, wrong turns, etc.), a fuel efficiency optimization (e.g., basedon known fuel ratings of the ridesharing vehicle), or the like. Forexample, any solution to the P v. NP problem later derived may also beincorporated into the optimization models. For at least one of (or eachof) the first, second, and third users, the determined drop-offlocations may differ from the desired destinations. Similarly, for atleast one of (or each of) the first, second, and third users, thedetermined pick-up locations may differ from current locations of theusers.

One or more of the pick-up and/or drop-off locations may besub-optimized. For example, route module 1220 may sub-optimize thedrop-off location of the first user in order to minimize a total waitingtime of the third user. An example of this embodiment is depicted inFIGS. 13C and 13F,

The sub-optimized drop-off location may be determined initially or maybe determined as an updated drop-off location. Additionally oralternatively, route module 1220 may sub-optimize the third pick-uplocation of the third user to minimize a total travel time of the firstand second users. An example of this embodiment is depicted in FIGS. 13Dand 13E. The sub-optimized pick-up location may be determined initiallyor may be determined as an updated pick-up location.

Any of the sub-optimizations described above may be subject to one ormore thresholds. For example, route module 1220 may decline asub-optimization if it would result in a walking time and/or distancefor a user above a threshold (e.g., 10 minutes, 15 minutes, etc., 0.25miles, 0.5 miles, 1 kilometer, or the like).

In embodiments where one or more determined pick-up locations differfrom starting points, route module 1220 may cause notices of thedetermined pick-up locations to be sent to the mobile communicationsdevices of each of the first, second, and third users. For example,route module 1220 may transmit data associated with the notices to themobile communications devices of each of the first, second, and thirdusers. For example, the data may include GPS coordinates of the pick-uplocations, physical addresses of the pick-up locations, or the like.Each mobile communication device may use received coordinates, areceived address, or the like to route (e.g., via walking) theassociated user front a current location of the device to the pick-uplocation. In another example, the data may include walking directions tothe determined pick-up locations.

Similarly, in embodiments where one or more determined drop-offlocations differ from desired destinations, route module 1220 may causenotices of the determined drop-off locations to be sent to the mobilecommunications devices of each of the first, second, and third users.For example, route module 1220 may transmit data associated with thenotices to the mobile communications devices of each of the first,second, and third users. For example, the data may include GPScoordinates of the drop-off locations, physical addresses of thedrop-off locations, or the like. Each mobile communication device mayuse received coordinates, a received address, or the like to route(e.g., via walking) the associated user (e.g., after being dropped off)to the drop-off location. In another example, the data may includewalking directions to the determined drop-off locations.

The pick-up locations and/or drop-off locations may be changed dependingon cancellations and re-assignments performed by arrival time module1230. For example, route module 1220 may change at least one pick-uplocation and/or drop-off location of at least one of (or each of) thefirst, second, and third users if a user's assignment is cancelledand/or if a user is re-assigned. Additionally or alternatively, routemodule 1220 may change at least one pick-up location and/or drop-offlocation of at least one of (or each of) the first, second, and thirdusers if route module 1220 determines that such a change would furtheroptimize the generated route for the ridesharing vehicle. Suchoptimization may be rejected if the new pick-up location and/or drop-offlocation would be too inconvenient for a corresponding user (e.g., byexceeding a threshold walking distance and/or time, or the like).Corresponding users may be notified of updates to drop-off locationsand/or pick-up locations as described above.

In embodiments where the third user is assigned to the first ridesharingvehicle, route module 1220 may generate an updated route for the firstridesharing vehicle to pick-up the third user. The updated route may becalculated like the original route described above while account for apick-up location and a drop-off location of the third user.Alternatively, route module 1220 may generate a route for the secondridesharing vehicle to send the second ride sharing vehicle toward anarea with predicted imminent passenger demand. For example, the areawith predicted demand is identified using a request history (e.g.,stored in database 1250) and/or real-time information (e.g., using eventinformation retrieved from one or more memories and/or using thecommunications interface). For example, route module 1220 may determinethat requests are expected in an area near a stadium after a sportingevent concludes.

As depicted in FIG. 12, memory 1200 may further include arrival timemodule 1230. Arrival time module 1230 may calculate a first expectedarrival time of the first ridesharing vehicle at one or more pick-uplocations (such as the third pick-up location). The expected arrivaltime may depend on a predicted route (e.g., calculated by route module1220 as explained above) for the first ridesharing vehicle. Arrival timemodule 1230 may also account for weather, traffic information, and/orinformation about emergency (e.g., fire, police, medical, etc.)activity, wrong turns, or the like (e.g., received using thecommunications interface and/or retrieved from one or more memories).

Similarly, arrival time module 1230 may calculate a second expectedarrival time of the second ridesharing vehicle at one or more pick-uplocations (such as the third pick-up location). The second expectedarrival time may be calculated similar to the first excepted arrivaltime, described above.

In embodiments where the second expected arrival time is sooner than thefirst expected arrival time and both the first expected arrival time andthe second expected arrival time are below a predetermined threshold(e.g., 15 minutes, 10 minutes, or the like), arrival time module 1230may assign the third user to the first ridesharing vehicle. Additionallyor alternatively, arrival time module 1240 may assign the third user tothe first ridesharing vehicle when an estimated delay for each of thefirst user and the second user is below another predetermined threshold(e.g., 30 minutes, 20 minutes, or the like). Accordingly, the assignmentof the third user may be rejected if such an assignment is tooinconvenient for the first user and/or the second user. Additionally oralternatively, arrival time module 1240 may assign the third user to thefirst ridesharing vehicle when the third desired destination of thethird user is in a same neighborhood as the second desired destinationof the second user and/or the first desired destination of the firstuser. For example, the third desired destination may be within aparticular range (e.g., 10 miles. 20 kilometers, etc.) of the seconddesired destination and/or the first desired destination, within a zonedefining the neighborhood of the second desired destination and/or thefirst desired destination (e.g., a square, a rectangle, a parallelogram,other regular shapes, irregular figures, or the like), etc.

Memory 1200 may further include a database access module 1240, and mayalso include database(s) 1250. Database access module 1240 may includesoftware instructions executable to interact with database(s) 1250, tostore and/or retrieve information (e.g., a request history as describedabove, weather information, traffic information, one or more maps, orthe like).

FIGS. 13A and 13B illustrate an example process for managing a fleet ofridesharing vehicles. At step 1300, a first user and a second user maybe assigned to a first ridesharing vehicle. Accordingly, a route may begenerated for the first ridesharing vehicle including a pick-up locationof the first user, a pick-up location of the second user, a desireddestination of the first user, and a desired destination of the seconduser. In addition, at step 1300, a third ride request from a third userhaving a third pick-up location may be received.

At step 1301, a first expected arrival time of the first ridesharingvehicle at the third pick-up location is determined (e.g., 10 min. Inthe example of FIG. 13A). Similarly, in step 1303, a second expectedarrival time of the second ridesharing vehicle at the third pick-uplocation is determined (e.g., 5 min in the example of FIG. 13A). Thearrival times may be calculated as explained above with respect toarrival time module 1230. In the example of FIG. 13A, the secondexpected arrival time is sooner than the first expected arrival time.

At step 1305, the third user is assigned to the first ridesharingvehicle and an updated route is generated for the first ridesharingvehicle to pick-up the third user. Although not depicted in FIG. 13B,the second ride sharing vehicle may be sent toward an area withpredicted imminent passenger demand (e.g., as explained above withrespect to route module 1220).

Although depicted without current locations of the first user, thesecond user, and the third user, the example of FIGS. 13A and 13B may bemodified to use one or more pick-up locations that differ from currentlocations of users and/or one or more drop-off locations that differfrom the desired destinations of the users,

FIG. 13C illustrates an example 1320 of scheduling picking up a thirduser after dropping off a first user and before dropping off a seconduser. Moreover, in the example of FIG. 13C, a drop-off location of thefirst user is sub-optimized to minimize a total waiting time of thethird user.

FIG. 13D illustrates an example 1330 of scheduling picking up a thirduser after dropping off a first user and before dropping off a seconduser. Moreover, in the example of FIG. 13D, a third pick-up location ofthe third user is sub-optimized to minimize a total travel time of thefirst and second users.

FIG. 13E illustrates an example 1340 of scheduling picking up a thirduser before dropping off a first user. Moreover, in the example of FIG.13E, a third pick-up location of the third user is sub-optimized tominimize a total travel time of the first and second users.

FIG. 13F illustrates an example 1350 of scheduling picking up a thirduser before dropping off a first user. Moreover, in the example of FIG.13F, a drop-off location of the first user is sub-optimized to minimizea total waiting time of the third user.

FIGS. 14A and 14B depict example method 1400 for managing a fleet ofridesharing vehicles. Method 1400 may, for example, be implemented byridesharing management server 150 of FIG.

At step 1411, server 150 may identify a first ridesharing vehicle and asecond ridesharing vehicle that are currently without passengers. Forexample, as explained above with respect to request module 1210, server150 identify the vehicles using signals received from second mobilecommunication devices associated with the ridesharing vehicles.Additionally or alternatively, server 1210 may identify the vehiclesbased on centralized tracking of capacity at ridesharing server 150(e.g., as explained above with respect to capacity tracking module 620).

Optionally, server 150 may receive, from a plurality of second mobilecommunication devices associated with a plurality of ridesharingvehicles (e.g., including the first ridesharing vehicle and the secondridesharing vehicle), information about a current location of each ofthe second mobile communications devices, derived from a locationcircuit (e.g., a GPS locator) within each of the second mobile devices.The plurality of second mobile communication devices may include aplurality of handheld devices associated with drivers of at least a partof the fleet of ridesharing vehicles and/or a plurality of transmittersembedded in autonomous vehicles (e.g., autonomous vehicle 130F) that area part of the fleet of ridesharing vehicles.

At step 1413, server 150 may receive a first request for a shared ridefrom a first user. For example, server 150 may receive the first requestusing one or more communications interfaces (such as communicationsinterface 360). In some embodiments, the first request may includeinformation related to a first pick-up location of the first user and afirst desired destination of the first user. For example, theinformation related to the first pick-up location may include a currentlocation of the first user or a user-requested pick-up location.

At step 1415, server 150 may receive a second request for a shared ridefrom a second user. For example, server 150 may receive the secondrequest using one or more communications interfaces (such ascommunications interface 360. In some embodiments, the second requestmay include information related to a second pick-up location of thesecond user and a second desired destination of the second user. Forexample, the information related to the second pick-up location mayinclude a current location of the second user or a user-requestedpick-up location.

Optionally, server 150 may receive the requests for shared rides from aplurality of first mobile communications devices associated with theplurality of users.

In some embodiments, server 150 may also determine pick-up locationsand/or drop-off locations for each of the first and second users. Asexplained above with respect to route module 1220, the pick-up locationsmay differ from current locations of users and/or the drop-off locationsmay differ from the desired destinations of the users. In suchembodiments, server 150 may cause notices of the determined pick-uplocations to be sent to the mobile communications devices of each of thefirst and second users. For example, as described above with respect toroute module 1220, server 150 may transmit data associated with thenotices to the mobile communications devices of each of the first andsecond users, and the data may include walking directions to thedetermined pick-up locations.

At step 1417, server 150 may assign the first user and the second userto the first ridesharing vehicle. At step 1419, server 1.50 may generatea route to the first ridesharing vehicle for picking up and dropping offeach of the first user and the second user. For example, as describedabove with respect to route module 1220, server 150 may generate theroute based on one or more optimization models run on the pick-uplocations of the first user and the second user as well as the desireddestinations (and/or drop-off locations) of the first user and thesecond user.

At step 1421, server 150 may receive via the communications interface, athird request for a shared ride from a third user. For example, server150 may receive the third request using one or more communicationsinterfaces (such as communications interface 360). In some embodiments,the third request may include information related to a third pick-uplocation of the third user and a third desired destination of the thirduser. For example, the information related to the third pick-up locationmay Include a current location of the third user or a user-requestedpick-up location.

Optionally, as explained above with respect to steps 1413 and 1415,server 150 may receive the third request from a first mobilecommunications device associated with the third user.

In some embodiments, as explained above with respect to steps 1413 and1415, server 150 may also determine a pick-up location and/or a drop-offlocation for the third user. As explained above with respect to routemodule 1220, the pick-up location may differ from current location ofthe third user and/or the drop-off location may differ from the desireddestinations of the third users. In such embodiments, server 150 maycause a notice of the determined pick-up location to be sent to themobile communications device of the third user. For example, asdescribed above with respect to route module 1220, server 150 maytransmit data associated with the notice to the mobile communicationsdevices of the third user, and the data may include walking directionsto the determined pick-up location.

In some embodiments, server 150 may receive the third request while boththe first user and the second user are riding in the first ridesharingvehicle. In such embodiments, server 150 may schedule picking up of thethird user before dropping off the first user or may schedule picking upthe third user after dropping off the first user and before dropping offthe second user.

At step 1423, server 150 may calculate a first expected arrival time ofthe first ridesharing vehicle at the third pick-up location. Forexample, as explained above with respect to arrival time module 1230 anddepicted in the example of FIG. 13A, server 150 may determine the firstexpected arrival time based on a predicted route (e.g., calculated byroute module 1220 as explained above) for the first ridesharing vehicle;weather, traffic information, and/or information about emergency (e.g.,fire, police, medical, etc.) activity (e.g., received using thecommunications interface and/or retrieved from one or more memories), orthe like.

At step 1425, server 150 may calculate a second expected arrival time ofthe second ridesharing vehicle at the third pick-up location. Forexample, as explained above with respect to arrival time module 1230 anddepicted in the example of FIG. 13A, server 150 may determine the secondexpected arrival time based on a predicted route (e.g., calculated byroute module 1220 as explained above) for the second ridesharingvehicle; weather, traffic information, and/or information aboutemergency (e.g., fire, police, medical, etc.) activity (e.g., receivedusing the communications interface and/or retrieved from one or morememories); wrong turns; or the like. The second expected arrival timemay be sooner than the first expected arrival time,

At step 1427, when both the first expected arrival time and the secondexpected arrival time are below a predetermined threshold, server 150may assign the third user to the first ridesharing vehicle. For example,as explained above with respect to arrival time module 1230, thepredetermined threshold may be less than twenty minutes.

Additionally or alternatively, server 150 may assign the third user tothe first ridesharing vehicle when an estimated delay for each of thefirst user and the second user is below another predetermined threshold.For example, as explained above with respect to arrival time module1230, the other predetermined threshold may be less than ten minutes.

Additionally or alternatively, server 150 may assign the third user tothe first ridesharing vehicle when the third desired destination of thethird user is in a same neighborhood as the second desired destinationof the second user. For example, as explained above with respect toarrival time module 1230, the third desired destination may be within aparticular range (e.g., 10 miles, 20 kilometers, etc.) of the seconddesired destination, within a zone defining the neighborhood of thesecond desired destination (e.g., a square, a rectangle, aparallelogram, other regular shapes, irregular figures, or the like),etc.

If any or all of the above conditions are not satisfied, server 150 mayassign the third user to the second ridesharing vehicle. If the secondridesharing vehicle is assigned to the third user, server 150 maygenerate a route to the second ridesharing vehicle for picking up anddropping off the third user.

In any of the above embodiments, server 150 may sub-optimize thedrop-off location of the first user in order to minimize a total waitingtime of the third user (e.g., as depicted in FIGS. 13C and 13F) or maysub-optimize the third pick-up location of the third user to minimize atotal travel time of the first and second users (e.g., as depicted inFIGS. 13D and 13E). As explained above with respect to arrival timemodule 1230

At step 1429, server 150 may generate an updated route for the firstridesharing vehicle to pick-up the third user. For example, as explainedabove with respect to route module 1220, server 150 may generate theroute based on one or more optimization models run on the pick-uplocations of the first, second, and third users as well as the desireddestinations (and/or drop-off locations) of the first, second, and thirdusers.

Method 1400 may further include additional steps. For example, method1400 may include generating a route for the second ridesharing vehicleto send the second ride sharing vehicle toward an area with predictedimminent passenger demand. As explained above with respect to routemodule 1220, the area with predicted demand may be identified using arequest history (e.g., stored in database 1250) and/or real-timeinformation (e.g., using event information retrieved from one or morememories and/or using the communications interface). Server 150 maygenerate such a route if the third user is not assigned to the secondridesharing vehicle.

Preposition in Empty Vehicles Based on Predicted Future Demand

In some embodiments, ridesharing management system 100 may collect alarge volume of information over time related to the demand forridesharing vehicles in geographical areas at particular times, places,etc. This historical data may be stored by ridesharing management system100, for example, in database 170 for future use. However, some existingridesharing management systems may encounter the technical problem ofhow to process the large amount of historical data that is collected andto use the historical data to provide an improved user experience forthe riders and/or drivers in the ridesharing network. This problem maybe particularly prevalent in systems for which the number and type ofridesharing vehicles present in a geographical area at a given point intime fluctuates based on human behavior, choices, traffic conditions,weather conditions, seasonality etc.

Some of the presently disclosed embodiments may address these technicalproblems by collecting and processing historical data to makepredictions of future demand in general zones of a geographical area.Further, in some embodiments, the ridesharing management system 100 mayuse the predicted future demand for ridesharing vehicles to prepositionvehicles with capacity to transport passengers in areas proximate to theexpected passengers. Further, the historical data may be used toselectively position user-driven vehicles and autonomous vehicles withina geographical area to better meet an expect demand based on historicalpatterns. For example, in one embodiment, the user-driven vehicles maybe positioned in a holding zone proximate a general zone with anexpected high demand while the autonomous vehicles may be assigned aroute (e.g., a circular route) through the general zone. Presentlydisclosed embodiments may offer one or more advantages over ridesharingsystems driven solely by present demand. For example, some embodimentsmay direct one or more vehicles to maintain a presence proximate an areaof expected high demand such that the high demand will be met eventhough present demand exists in another geographical area. These andother features of presently disclosed embodiments are discussed in moredetail below.

FIG. 15 is a diagram illustrating an example of memory 320 storing aplurality of modules, consistent with the disclosed embodiments. Themodules may be executable by at least one processor to perform variousmethods and processes disclosed herein. Further, it should be noted thatmemory 320 may store more or fewer modules than those shown in FIG. 15,depending on implementation-specific considerations.

As illustrated in FIG. 15, memory 320 may store software instructions toexecute a historical data module 1501, a holding zone selection module1502, an instruction generation module 1503, a database access module1504, and may also include database(s) 1505. Historical data module 1501may include software instructions for storing, receiving, and/or usinghistorical data associated with past demand for ridesharing vehicles,e.g., in a geographical area. Holding zone selection module 1502 mayinclude software instructions for selecting a holding zone forpropositioning one or more empty (i.e., without passengers) ridesharingvehicles in preparation for a predicted imminent demand for ridesharingservices. Instruction generation module 1503 may include softwareinstructions for generating control signals for directing one or moreridesharing vehicles to one or more holding zones despite otherridesharing demand in the geographical area. Database access module 1504may include software instructions executable to interact withdatabase(s) 1505, to store and/or retrieve information (e.g., historicaldata associated with past demand).

Historical data module 1501 may include software instructions forstoring, receiving, and/or accessing historical data associated withpast demand for ridesharing vehicles in a geographical area. Thehistorical data may include any information associated with demand forridesharing vehicles at a prior point in time. For example, thehistorical data may include any historical information that may be usedto analyze, estimate, or determine past demand for ridesharing vehicles,such as data collected about pick-up locations, days, times, etc. ofprior ride requests. The historical data may also include informationcollected about weather conditions associated with a prior ride request.For example, the historical data may indicate that fewer rides arerequested on a sunny day than on a rainy day in the same month.

The historical data may also include raw data tracking previousridesharing requests, such as a log created contemporaneously as pastrequests for a ride were initiated. The log may include, for example, anindication of the time and/or date of the request, the location of theuser when the request was initiated, the time it look for the user tobegin a trip in a ridesharing vehicle, etc. In other embodiments,however, the historical data may include analyzed and/or compiled data,such as a ride request frequency defined by a total number of riderequests received over a given period of time in a given area. Forfurther example, the historical data may include data analyzed based onproximity to a given venue when a show or event ends, begins, or isoccurring. For example, the historical data may include an average ormedian number of rides requested when a concert, play, etc. ends at agiven venue on a weekend night.

The geographical area may include any physical region, depending onimplementation-specific considerations. For example, in one embodiment,the geographical area may be a legally defined area, such as a city, astate, a county, a country, etc. However, in other embodiments, thegeographical area may be defined by the ridesharing management system100 to include, for example, a certain numbers of streets, square miles,landmarks, etc. Indeed, the geographical area may be any physical areawith boundaries assigned based on any suitable criteria for the givenimplementation.

In some embodiments, historical data module 1501 may store thehistorical data associated with past demand for one or more ridesharingvehicles in a fleet of ridesharing vehicles in database 1505. Thehistorical data may be stored contemporaneously with its collection(e.g., within 1-2 minutes of its collection), at specific time intervals(e.g., once a day, once a month, biweekly, etc.), when initiated by auser, or in any other suitable manner The stored historical data maythen be accessed by historical data module 1501, e.g., through databaseaccess module 1504, at a later point in time than the data wascollected.

In one embodiment, the historical data may be used to predict imminentdemand of ridesharing requests. As used herein, predicted imminentdemand refers to demand that is predicted to occur within apredetermined time period from a given point in time. The predeterminedtime period may be within seconds (e.g., 10 seconds, 20 seconds, 30seconds, etc.), within 1 minute, 5 minutes, 10 minutes, 15 minutes, 20minutes, 25 minutes, 30 minutes, 35 minutes, 40 minutes, 45 minutes, 50minutes, 55 minutes, or 1 hour from a given point in time. Further, insome embodiments, to predict imminent demand, the amount of demand mayneed to meet or exceed a predetermined threshold. For example, thedemand may need to meet a predicted number of ride requests in a givenperiod of time, such as greater than 10 requests over a 10 minute periodof time, greater than 100 requests over 10 minutes, etc.

For example, in one embodiment, predicting imminent demand ofridesharing requests may include predicting general zones in ageographical area associated with the imminent demand. The general zonesmay be any physical region located within a geographical area, dependingon implementation-specific considerations. For example, in oneembodiment, the geographical area may be a city, and the general zonemay be a portion of the city where imminent demand is predicted to occurwithin the next 15 minutes. In another embodiment, the general zone maybe defined to be an area within a certain distance from a venue, such asa concert hall, movie theatre, school, workplace, mall, airport, etc.For example, the general zone may be defined to be a certain number ofsquare miles surrounding the venue.

Holding zone selection module 1502 may include software instructions forselecting a holding zone for prepositioning one or more emptyridesharing vehicles in order to expedite satisfaction of the predictedimminent demand. As used herein, empty ridesharing vehicles may refer tovehicles that are not carrying a passenger who requested a ride,including vehicles driven by a user and/or an autonomous vehicles. Suchvehicles may be prepositioned before a predicted imminent demandmaterializes (i.e., before the ride requests are made). In this way, thesatisfaction of the users requesting rides when the demand materializesmay be increased compared to systems that do not include prepositionedvehicles.

As used herein, a holding zone may be any physical area in thegeographical area where one or more ridesharing vehicles may be located.For example, the holding zone may be a neighborhood (e.g., an areabounded by a set of streets), a specific location (e.g., a parking lot,parking garage, etc.), or a combination thereof. Further, the holdingzone may include parking spots, predetermined holding patterns/routes,or any other areas for ridesharing vehicles to congregate. For example,in one embodiment, a holding zone may include parking spots for vehiclesdriven by users to wait for the predicted imminent demand tomaterialize. In some embodiments, a holding zone may include acontinuous route for autonomous vehicles to follow while waiting for theimminent demand to materialize. Still further, one or more of theholding zones may include a location where one or more partially orfully electrically-powered vehicles may charge an energy storage device(e.g., a battery) while waiting for a user assignment.

In some embodiments, the holding zone for a particular ridesharingvehicle may be selected from a plurality of pre-identified holding zonesstored in memory, e.g., database 1505. The pre-identified holding zonesmay be areas where the ridesharing management system 100 provider haspre-negotiated, for the ridesharing vehicles to be located. For example,the ridesharing management system 100 provider may have agreements withowners of certain garages, parking lots, etc. Further, the holding zonefor a specific ridesharing vehicle may be selected using real-time data(i.e., data collected within 10 seconds, 20 seconds, 30 seconds, 40seconds, 50 seconds, a minute, 5 minutes, 10 minutes, 20 minutes, etc.,of when the data is analyzed or used). For example, the holding zone fora given vehicle may be selected to be close to downtown office buildingsduring rush hour, a football stadium when a football game is expected toend, etc.

Indeed, when selecting a holding zone for a specific ridesharingvehicle, holding zone selection module 1502 may take into account one ormore implementation-specific considerations. In one embodiment, theholding zone for a given vehicle may be selected using data aboutpassenger-capacity of the vehicle (e.g., vans or high capacity vehiclesmay be sent to holding zones where a large number of passengers willlikely need a ride together, such as near a concert venue). In otherembodiments, a holding zone may be selected for a specific ridesharingvehicle using data about a shift of a driver of the vehicle. Forexample, a vehicle driven by a driver for a longer period of time (e.g.,4 hours) may be selected to go to the holding zone instead of a vehicledriven by a driver for a shorter period of time (e.g., 15 minutes).

Further, in some embodiments, holding zone selection module 1502 may beconfigured to identify a plurality of holding zones and direct aplurality of empty ridesharing vehicles to the plurality of holdingzones. In some embodiments, the plurality of empty ridesharing vehiclesmay be selectively paired with the plurality of holding zones. Forexample, based on the predicted general zones in the geographical area,a single empty ridesharing vehicle may be directed to a first holdingzone (e.g., near a location where demand is expected to be low, such asa small office building) and at least two empty ridesharing vehicles toa second holding zone (e.g., near a location where demand is expected tobe comparably higher, such as a large office building).

Instruction generation module 1503 may include software instructions forgenerating and/or sending instructions to at least one ridesharingvehicle. For example, in some embodiments, instructions directing one ormore ridesharing vehicles to one or more holding zones identified forthe respective vehicle(s) may be sent to mobile communication device(s)in the respective vehicles. In some embodiments, the instructions mayinclude an indication that the one or more ridesharing vehicles shouldmaintain a presence in the one or more holding zones despite otherridesharing demand in the geographical area. That is, a ridesharingvehicle may be instructed to stay in a holding zone in anticipation ofpredicted imminent demand instead of picking up a passenger currentlydemanding a ride in the geographical area. In this way, predicted surgesin demand may be accommodated acid/or prioritized over contemporaneousand/or unexpected demand.

Database 1505 may be configured to store any type of information of useto modules 1501-1504, depending on implementation-specificconsiderations. For example, in embodiments in which historical datamodule 1501 is configured to store historical data associated with pastdemand for ridesharing vehicles, database 1505 may store the historicaldata. Further modules 1501-1504 may be implemented in software,hardware, firmware, a mix of any of those, or the like. For example, ifthe modules are implemented in software, they may be stored in memory320. However, in sonic embodiments, any one or more of modules 1501-1504and data associated with database 1505, may, for example, be stored inprocessor 310 and/or located on server ridesharing management server150, which may include one or more processing devices. Processingdevices of server 150 may be configured to execute the instructions ofmodules 1501-1504. In some embodiments, aspects of modules 1501-1504 mayinclude software, hardware, or firmware instructions (or a combinationthereof) executable by one or more processors, alone or in variouscombinations with each other. For example, modules 1501-1504 may beconfigured to interact with each other and/or other modules of server150 to perform functions consistent with disclosed embodiments.

FIG. 16 illustrates an example environment including a geographical area1600 in which ridesharing vehicles 130F, 1624, and 1626 are dispatchedand under control of ridesharing management system 100. In theillustrated embodiment, processor 310 has determined that thegeographical area 1600 includes a first general zone 1602, a secondgeneral zone 1604, and a third general zone 1606. In the illustratedembodiment, the first and second general zones 1602, 1604 have beenpredicted to be associated with imminent demand for rides. Therefore,the first general zone 1602 includes a first holding zone 1608 thatenables prepositioning of one or more ridesharing vehicles in the firstgeneral zone 1602. Likewise, the second general zone 1604 includes asecond holding zone 1610 that enables prepositioning of one or moreridesharing vehicles in the second general zone 1604. In the illustratedembodiment, the third general zone 1606 includes only a parking lot1612. Therefore, the third general zone 1606 has been associated with alack of imminent demand and, accordingly, has not been assigned aholding zone.

In some embodiments, the processor 310 may be configured to receive arideshare request from a mobile communications device of a user in avicinity of a specific ridesharing vehicle driving toward a selectedholding zone, but assign the ride to another vehicle farther away fromthe user to pick up the user. For example, in the first general zone1602, user 130A may request a ride via device 120A while standingoutside user's house 1614. Vehicle 130F may be driving toward the firstholding zone 1608, as indicated by arrows 1616, when the ride request ofuser 130A is received. However, vehicle 1618, which is farther from user130A when the ride request is received, may be assigned to pick up user130A while vehicle 130F may continue to the first holding zone 1608.

The foregoing feature may offer one or more advantages over systems thatconnect user 130A to vehicle 130F on the basis of closest proximity. Forexample, by directing vehicle 130F to the first holding zone 1608, theprocessor 310 may reduce or prevent the likelihood that a demand surgethat occurs when a concert ends at concert hall 1620 is not met. Inother words, user 130A may experience a delay in being picked up for aride to expedite satisfaction of the users who may be in concert hall1620 for a concert that is about to end.

In other embodiments, however, the processor 310 may receive a ridesharerequest from a mobile communications device of a user in a vicinity of aspecific ridesharing vehicle driving toward a selected holding zone andsend a message to the specific ridesharing vehicle to pick up the userwhen the desired destination of the user is in proximity to the selectedholding zone. For example, in some embodiments, the processor 310 maydirect vehicle 130F to pick up user 130A on its way to the first holdingzone 1608 when the user's destination is ice cream shop 1622, which isproximate the first holding zone 1608.

In some embodiments, one or more vehicles in a holding zone may bedirected to leave a holding zone to pick up a passenger. For example,the processor 310 may be configured to receive a rideshare request frommobile communications device 120A of user 130A in a vicinity of aselected holding zone 1608. The processor 310 may then to send a messageto an empty rideshare vehicle 130F that has been positioned in theselected holding zone 1608 to pick-up user 130A. The instructions mayinclude routing instructions to a pick-up location, such as house 1614,in a vicinity of the selected holding zone 1608.

In some embodiments, the processor 310 may assign passengers to one ormore ridesharing vehicles, such as vehicle 1624 and vehicle 1626. In oneembodiment, each of vehicles 1624 and 1626 may be already transportingone or more users and be assigned one or more additional users forsimultaneous transportation. However, in another embodiment, each ofvehicles 1624 and 1626 may be transporting a single user. Further, theprocessor 310 may track assignments of vehicle 1624 and vehicle 1626 toidentify that vehicles 1624 and 1626 are about to be without passengersand without future assignments. Vehicle 1624 may be directed towardsecond holding zone 1610, as indicated by arrow 1628. The processor 310may direct vehicle 1624 to second holding zone 1610 based on the currentlocation of the vehicle (e.g., on a road headed toward second holdingzone 1610) and a predicted imminent demand proximate second holding zone16.1.0. In the illustrated embodiment, imminent demand may be predictedbecause storm clouds 1630 indicate that it is likely to rain in secondgeneral zone 1604.

Vehicle 1626 may be directed to another holding zone (not illustrated inFIG. 16) in a direction 1632 away from second holding zone 1610. Theprocessor 310 may direct vehicle 1626 to another holding zone other thansecond holding zone 1610 based on the current location of vehicle 1626(e.g., on a road headed away from second holding zone 1610) and apredicted imminent demand proximate another holding zone. However, inother embodiments, vehicles 1624 and 1626 may be directed to separateholding zones based on a variety of implementation-specificconsiderations. For example, vehicle 1624 may be closer to secondholding zone 1610 than to first holding zone 1608 such that vehicle 1624may be assigned to meet the demand in second general zone 1604 insteadof first general zone 1602. For further example, in some embodiments,one or more of the vehicles may be directed to another holding zone ifsecond holding zone 1610 is at full capacity (i.e., it cannotaccommodate any more vehicles).

In some embodiments, one or more of the holding zones may include alocation where one or more ridesharing vehicles may park while waitingfor a user assignment. For example, second holding zone 1610 includesparking spots 1634. In some embodiments, one or more of the holdingzones may include a route along which a vehicle may be directed to drivewhile awaiting a pick-up assignment. For example, second holding zone1610 includes circular route 1636. In one embodiment, manually-drivablevehicles may be directed to parking spots 1634 and autonomous vehiclesmay be directed to route 1636. In the illustrated embodiment, route 1636is shown as a circular route proximate to parking spots 1634. However,in other embodiments, route 1636 may be a series of streets in aneighborhood, or any other suitable path one or more vehicles can followwhile waiting for a passenger assignment.

FIG. 17A illustrates a flowchart of an exemplary method 1700 fordispatching at least one ridesharing vehicle, in accordance with someembodiments of the present disclosure. The method 1700 may be carriedout, for example, by processor 310. For exemplary purposes only, method1700 for dispatching at least one ridesharing vehicle is described withrespect to processing device 310 cooperating with memory 320 to executemodules 1501-1504. In accordance with method 1700, processor 310 maystore historical data associated with past ridesharing demand at block1702. For example, historical data module 1501 may store historical datain database 1505 as it is collected when ride requests are initiated fora ride. The stored historical data may then be accessed at a later pointin time at block 1704. For example, historical data module 1501 mayaccess the historical data via database access module 1504.

Historical data module 1501 may use the accessed historical data topredict imminent demand of ridesharing requests at block 1706. Forexample, the processor 310 may predict that first general zone 1602 andsecond general zone 1604 in geographical area 1600 will likelyexperience imminent demand for ridesharing requests. Holding zoneselection module 1502 may select a holding zone for prepositioning atleast one ridesharing vehicle to address the predicted imminent demandat block 1708. For example, the processor 310 may select second holdingzone 1610 for vehicle 1624 based on predicted imminent demand in secondgeneral zone 1604. The imminent demand may be predicted, for example,based on the likelihood of rain given storm clouds 1630. The processor310 may send instructions to at least one rideshare vehicle (e.g.,vehicle 1624) to travel to the selected holding zone (e.g., secondholding zone 1610) at block 1710.

FIG. 17B illustrates a flowchart of an exemplary method 1712 fordispatching a plurality of ridesharing vehicles, in accordance with someembodiments of the present disclosure. The method 1712 may be carriedout, for example, by processor 310. For exemplary purposes only, method1712 for dispatching at least one ridesharing vehicle is describedherein with respect to processing device 310 cooperating with memory 320to execute modules 1501-1504. In accordance with method 1712, processor310 may receive location information from a plurality of ridesharingvehicles at block 1714. For example, processor 310 may receive locationinformation from vehicle 1624 and vehicle 1626. The location informationmay include any information that enables the processor 310 to determinevehicle location within geographical area 1600. For example, thelocation information may include global positioning system (“GPS”)coordinates, current speed, current direction of travel, etc.

The processor 310 may assign additional users to one or more of theplurality of ridesharing vehicles for simultaneous transportation withusers already being transported in the ridesharing vehicles at block1716. For example, vehicle 1624 may be carrying user 130A when processor310 assigns vehicle 1624 an additional user 130B to transport. In thisway, user 130A and user 130B may be simultaneously transported byvehicle 1624 because at least a portion of the trip of user 130Aoverlaps with at least a portion of the trip of user 130B such that theyare in vehicle 1624 at the same time for a portion of their respectivetrips.

The processor 310 may identify first and second ridesharing vehiclesabout to be without passengers and without future assignments at block1718. For example, the processor 310 may determine that vehicle 1624 hasstopped at the final destination of its passengers and has not acceptedanother trip request. Likewise, the processor 310 may determine thatvehicle 1626 is 0.1 miles from the final destination of its passengersand has not accepted another trip request. Based on this information,the processor 310 may direct the first ridesharing vehicle to a firstholding zone at block 1720 and the second ridesharing vehicle to asecond holding zone at block 1722. In some embodiments, the firstridesharing vehicle and the second ridesharing vehicle may be directedto the holding zones to which each vehicle is closest. In otherembodiments, the ridesharing vehicles may be directed based on a varietyof implementation-specific considerations, such as holding zonecapacity, holding zone occupancy rate, expected level of demand in ageneral zone or each zone, length of time the vehicle has been driven.etc.

Dynamic Route Planning

In some embodiments, ridesharing management system 100 may collect alarge volume of information over time related to available routes forridesharing vehicles in geographical areas at particular times, places,etc. This data may be stored by ridesharing management system 100, forexample, in database 170 for future use. However, some existingridesharing management systems may encounter the technical problem ofhow to process the large amount of stored data and large number ofpossible routes and to use the data to provide an improved userexperience for the riders and/or drivers in the ridesharing network.This problem may be particularly prevalent in systems for which thenumber and type of ridesharing vehicles present in a geographical areaat a given point in time fluctuates based on human behavior, choices,traffic conditions, weather conditions, etc.

Some of the presently disclosed embodiments may address these technicalproblems by collecting and processing past route data and/or currentvariables affecting possible vehicle routes to determine an optimalroute for a particular ridesharing vehicle through a given geographicalarea. For example, presently disclosed embodiments may take into accounta capacity of a given ridesharing vehicle and how much of that capacityis being utilized at a given point in time to determine a vehicle route.For instance, in one embodiment, the ridesharing management system 100may route a particular ridesharing vehicle along a route that results ina later arrival time for one or more passengers, as compared to anotheravailable route, when the ridesharing vehicle is operating with adifferent, e.g., higher capacity. In this way, a greater number of usersmay be serviced more quickly compared to systems that route based onlyon expected arrival time and not other variables.

FIG. 18 is a diagram illustrating an example of memory 320 storing aplurality of modules, consistent with the disclosed embodiments. Themodules may be executable by at least one processor to perform variousmethods and processes disclosed herein. Further, it should be noted thatmemory 320 may store more or fewer modules than those shown in FIG. 18,depending on implementation-specific considerations.

As illustrated in FIG. 18, memory 320 may store software instructions toexecute an input data collection module 1801, a capacity statusdetermination module 1802, a vehicle routing module 1803, a databaseaccess module 1804, and may also include database(s) 1805. Input datacollection module 1801 may include software instructions for receivinginput data (e.g., user ride requests, current location of ridesharingvehicles, etc.) from one or more sources. Capacity status determinationmodule 1802 may include software instructions for determining a capacitystatus for one or more ridesharing vehicles based on a known passengercapacity. Vehicle routing module 1803 may include software instructionsfor sending one or more ridesharing vehicles to pick up user(s) anddirecting the vehicles along a determined route. Database access module1804 may include software instructions executable to interact withdatabase(s) 1805, to store and/or retrieve information (e.g.,geographical maps associated with a geographical area in which aridesharing vehicle is operating).

Input data collection module 1801 may include software instructions forreceiving input data related to ridesharing vehicle routing. The inputdata may be any data relevant to directing one or more ridesharingvehicles along a route. For example, the input data may include riderequests from a plurality of users headed to different destinations. Theride requests may include information such as a starting point, adesired destination, an identity of the user, a rating of the user, etc.Moreover, the input data may be a current location of one or moreridesharing vehicles. The current location of a ridesharing vehicle maybe received, for example, from a mobile communications device (e.g., asmartphone, tablet, etc.) associated with (e.g., located in thepassenger cabin) the ridesharing vehicle.

Capacity status determination module 1802 may include softwareinstructions for determining a capacity status for one or moreridesharing vehicles. The capacity status of a vehicle at a given pointin time may be any variable that captures the relative availablecapacity of the vehicle compared to a known capacity of the vehicle whenempty. For example, the capacity status and/or known capacity may bemeasured with respect to a numerical value for each passenger. Forexample, if the known passenger capacity of a vehicle is 4 riders and 1rider is in the vehicle, the capacity status of the vehicle is 3.Further, the capacity status and/or known capacity of the vehicle mayinclude the vehicle's driver or may be computed without counting thevehicle's driver (e.g., in the case of an autonomous vehicle).

In sonic embodiments, the capacity status may be adjusted based onfactors other than the number of passengers currently in the vehicle butthat affect the available capacity of the vehicle. For example, if apassenger has a suitcase that is taking up the space in the vehicle, thecapacity status availability may be reduced by 2 passengers instead of 1passenger. As another example, if a passenger takes up more than oneseat in the vehicle, the capacity status may be reduced accordingly.Additionally, the capacity status may be adjusted automatically basedon, for example, metadata associated with a user's ride request, and/ormanual inputs, such as the driver's observations when the passenger ispicked up.

Capacity status determination module 1802 may also include softwareinstructions for retrieving, receiving, and/or determining a capacitythreshold for a given ridesharing vehicle. The capacity threshold may beany variable that captures the lack of further availability of a vehicleto accommodate transport of additional passengers and/or items. Forexample, the capacity threshold may be a percentage of the knownpassenger capacity of the given ridesharing vehicle. In one embodiment,the capacity threshold may be set at 75% of the known passenger capacitysuch that if 3 of the 4 available seats in a vehicle are full, thecapacity threshold is met. In other embodiments, the capacity thresholdmay be determined based on a vehicle ride type selected and/or paid forby a given rider. For example, in one embodiment, a user may select aprivate ride such that the capacity threshold is set to one passenger.

In some embodiments, the capacity threshold may be set based on thepassenger-capacity of a given ridesharing vehicle. For example, in someembodiments, the capacity threshold may be one person less than apassenger-capacity of a ridesharing vehicle. In other embodiments, thecapacity threshold may be two persons less than a passenger-capacity ofthe ridesharing vehicle. In other embodiments, the capacity thresholdmay be three persons less than a passenger-capacity of the ridesharingvehicle. In another embodiment, the capacity threshold may be fourpersons less than a passenger-capacity of the ridesharing vehicle.Further, the capacity threshold may be any given number of passengers,such as two passengers, three passengers, four passengers, etc.

Further, in some embodiments, a particular vehicle type may have a knownpassenger capacity (e.g., a four door vehicle may accommodate 4passengers other than the driver). However, certain sub-types of thevehicle type may nevertheless be assigned a capacity status or have acapacity threshold adjusted up or down for the particular vehicle type.For example, a small vehicle with reduced room inside may be assigned alower known passenger capacity or may be found to meet a thresholdcapacity sooner than a larger vehicle. Likewise, a large vehicle withincreased room inside may be assigned a higher known passenger capacityor may be found to reach a capacity threshold later than a smallervehicle.

Capacity status determination module 1802 may also include softwareinstructions for determining whether the capacity status of aridesharing vehicle meets the capacity threshold. For example, themodule 1802 may compare a normalized capacity status to a normalizedcapacity threshold to determine if the threshold is met. The capacitystatus and capacity threshold may be normalized to both be representedas a whole number, percentage, ratio, etc. to enable comparison. In someembodiments, if the capacity status of the vehicle is below the capacitythreshold, the ridesharing vehicle may be directed to pick up one ormore additional passengers. Further, if the capacity status of thevehicle meets or exceeds the capacity threshold, the ridesharing vehiclemay be directed to a route that transports the existing passengers totheir respective destinations as quickly as possible.

Vehicle routing module 1803 may include software instructions forrouting a ridesharing vehicle to pick up and/or transport one or moreusers. For example, in response to the ride requests received by inputdata collection module 1801 from the plurality of users headed todiffering destinations, vehicle routing module 1803 may send theridesharing vehicle to pick up the plurality of users headed to thedifferent destinations. That is, vehicle routing module 1803 may directthe ridesharing vehicle along one or more routes through the surroundingenvironment based on the current state of one or more variables.Further, the route to which the ridesharing vehicle is assigned may bedynamically adjusted during transportation of the plurality of users toredirect the ridesharing vehicle to optimize one or more performancevariables.

For example, in one embodiment, vehicle routing module 1803 may directand/or redirect the ridesharing vehicle along one or more routes basedon the capacity status of the ridesharing vehicle and/or one or moreadditional variables. In one embodiment, the ridesharing vehicle may bedirected along a first route resulting in a first set of arrival timesfor the plurality of users e.g., if the capacity status of theridesharing vehicle is below the capacity threshold). The ridesharingvehicle may also be directed along a second route resulting in a secondset of arrival times for the plurality of users (e.g., if the capacitythreshold is met). In some embodiments, the second set of arrival timesmay be earlier than the first set of arrival times. This may occur, forexample, because the second route includes a toll road that is moredirect than a non-toll road, a highway that is faster than side streetsor streets with traffic signals, or any other factor affecting triplength. In one embodiment, each of the respective arrival times of eachrespective passenger may be earlier for the second route than the firstroute. However, in other embodiments, the second route may result in aset of arrival times that are generally earlier than the first route.That is, each respective arrival time of each passenger is notnecessarily earlier on the second route than the first route, but atleast one passenger may arrive earlier for the second route than thefirst route.

In one embodiment, the ridesharing vehicle may be directed or redirectedto the second route when the capacity of the ridesharing vehicle isbelow the capacity threshold but imminent demand is predicted in an areanear at least one drop-off location associated with at least onepassenger. For example, only one passenger may be in a vehicle that canaccommodate three passengers. However, the current passenger'sdestination may be a concert hall near a sports arena that is hosting asporting event that is expected to end within a few minutes of thepassenger's estimated arrival time at the concert hall. Accordingly, inorder to better meet the expected demand proximate the sports arena,ridesharing management system 100 may direct the ridesharing vehicle totake the second, faster route.

In another embodiment, the ridesharing vehicle may be directed orredirected to the second route when the capacity status of theridesharing vehicle is below the capacity threshold but anotherridesharing vehicle is driving along a similar route to the first route.A “similar route” may be any route that partially or fully overlaps withthe first route. For example, if the first route includes driving onportions streets A, B, C, and D, and another route includes driving onthe same portions of streets A and B, the routes may be similar routes.The foregoing feature may enable greater efficiencies in the ridesharingsystem because the likelihood that multiple vehicles are traveling alongthe same or similar routes may be reduced, thus enabling duplicativeroutes to be reduced or eliminated.

Database 1805 may be configured to store any type of information of useto modules 1801-1804, depending on implementation-specificconsiderations. For example, in embodiments in which vehicle routingmodule 1803 is configured to access one or more prior-stored maps ofgeographical areas, database 1805 may store the geographical maps.Further, modules 1801-1804 may be implemented in software, hardware,firmware, a mix of any of those, or the like. For example, if themodules are implemented in software, they may be stored in memory 320.However, in some embodiments, any one or more of modules 1801-1804 anddata associated with database 1805, may, for example, be stored inprocessor 310 and/or located on server ridesharing management server150, which may include one or more processing devices. Processingdevices of server 150 may be configured to execute the instructions ofmodules 1801-1804. In some embodiments, aspects of modules 1801-1804 mayinclude software, hardware, or firmware instructions (or a combinationthereof) executable by one or more processors, alone or in variouscombinations with each other. For example. modules 1801-1804 may beconfigured to interact with each other and/or other modules of server150 to perform functions consistent with disclosed embodiments,

FIG. 19 illustrates a schematic of an example environment including ageographical area 1900 in which autonomous ridesharing vehicle 130F anduser-driven vehicle 1902 (not shown to scale for illustrative purposes)are dispatched and under control of ridesharing management system 100.In the illustrated embodiment, processor 310 has received ride requestsfrom the plurality of users 130A-C via communications devices 120A-C. Inthe illustrated example, user 130A has requested a ride from thestarting point at house 1904 to desired destination at school 1906.Further, user 130B has requested a ride from the starting point at house1908 to desired destination at library 1910. Similarly, user 130C hasrequested a ride from the starting point at house 1912 to desireddestination at park 1914.

In the illustrated example, ridesharing management system 100 hasdetermined a first route 1920 resulting in a first set of arrival timesfor users 130A-C. For example, first route 1920 may result in user 130Aarriving at school 1906 at 9:00 am, user 130B arriving at library 1910at 9:05 am, and user 130C arriving at park 1914 at 9:10 am, Similarly,ridesharing management system 100 has determined a second route 1922resulting in a second set of arrival times for users 130A-B. Forexample, second route 1922 may result in user 130A arriving at school1906 at 8:55 am, user 130B arriving at library 1910 at 9:00 am, and user130C being picked up by another ridesharing vehicle. In this embodiment,the second set of arrival times may be earlier than the first set ofarrival times because user 130A arrives at 8:55 am when route 1922 istaken but at 9:00 am when route 1920 is taken. Similarly, the second setof arrival times may be earlier than the first set of arrival timesbecause user 130A arrives at 9:00 am when route 1922 is taken but at9:05 am when route 1920 is taken.

In some embodiments, processor 310 may selectively direct vehicle 1902along the first route 1920 and/or the second route 1922 based on thecapacity status of the vehicle 1902. For example, vehicle 1902 in theillustrated embodiment includes driver 130D having mobile communicationsdevice 120E mounted in vehicle 1902. A passenger 1924 is beingtransported by vehicle 1902. However, seats 1926 and 1928, as well as anon-illustrated middle seat in the back, remained unoccupied. Therefore,vehicle 1902 may be determined to be below a capacity threshold for thevehicle, which may be set at 4 passengers. Therefore, vehicle 1902 maybe determined to have availability to pick up 3 passengers to fill theremaining seats in vehicle 1902. Thus, in one embodiment, vehicle 1902may be directed along the first route 1920 to pick up passengers 130A-C.

In another embodiment, however, vehicle 1902 may be directed alongsecond route 1922. For example, passenger 1924 may have a large bag orsuitcase taking up one seat in vehicle 1902 such that only twoadditional passengers can be transported simultaneously with passenger1924 and his belongings. In such an embodiment, vehicle 1902 may bedirected along second route 1922 to pick up passengers 130A and 13013,but not passenger 130C.

As another example, vehicle 1902 may be directed along second route 1922when the capacity status of vehicle 1902 is below the capacity thresholdbut at least one of the users 130A-C booked an expedited ride (e.g., bypaying a higher price for the ride). For example, user 130A may book anexpedited ride to school 1906 such that vehicle 1902 is directed alongsecond route 1922 to get user 130A to school 1906 more quickly than iffirst route 1920 was taken.

In another embodiment, vehicle 1902 may be selectively directed orredirected along the first route 1920 and the second route 1922 based onfeedback received from one or more tracking systems. For example, in oneembodiment, ridesharing management system 100 may receive real timetraffic data (e.g., data from governmental traffic tracking cameras)updated every 30 seconds, every minute, every 5 minutes, every 10minutes, etc. as traffic changes. In one embodiment, vehicle 1902 may bedirected along the first route 1920 when the capacity threshold is metbut traffic congestion is identified along the second route 1922. Insome embodiment, the traffic congestion may be atypical for the givenday, time, and/or route.

In another embodiment, vehicle 1902 may be directed along the secondroute 1922 based on real time traffic data. For example, vehicle 1902may be directed to the second route when the capacity status of vehicle1902 is below the capacity threshold and traffic congestion isidentified along first route 1920. In some embodiments, the trafficcongestion along first route 1920 may be atypical for the given day,time, and/or route.

In some embodiments, ridesharing management system 100 may receiveinputs from mobile communications devices associated with users 130A-C,vehicle 130F, and/or vehicle 1902 throughout the continuous operation ofthe ridesharing dispatch system. These inputs may be used to direct oneor more of the ridesharing vehicles in the system to different routes,to pick up different passengers, etc. For example, in one embodiment,processor 310 is configured to continuously receive location informationfrom the mobile communications device 120E associated with theridesharing vehicle 1902 to estimate arrival time of vehicle 1902 at thepick up location 1904 of one of the plurality of users 130A and toreassign a different ridesharing vehicle (e.g., 130F) when the processor310 predicts a delay in arrival of the ridesharing vehicle 1902 at thepick-up location 1904. For example, a delay may be expected becausevehicle 1902 needs to stop for fuel, has encountered traffic, got intoan accident, experienced mechanical malfunctions, got pulled over by thepolice, made a wrong turn, etc.

In another embodiment, the processor 310 is configured to continuouslyreceive location information from mobile communications device 120Aassociated with one of the plurality of users 130A, to estimate arrivaltime at the pick-up location 1904 of the user 130A and to reassign adifferent ridesharing vehicle (e.g., 130F) when the processor 310estimates that that user 130A will arrive after the ridesharing vehicle1902. For example, if user 130A requests a ride while visiting aneighbor, mobile communications device 120A may reflect that user 130Ais not at pickup location 1904. Processor 310 may further compute thatit will take user 130A more time to reach house 1904 than vehicle 1902given the current locations of user 130A and vehicle 1902. Therefore,processor 310 may send a different vehicle, such as autonomous vehicle130F to pick up user 130A.

In another embodiment, the processor 310 is configured to continuouslyreceive location information from a communications device (e.g. mobilecommunications device 120A) associated with the ridesharing vehicle1902, to estimate arrival time at the pick-up location 1904 and toreassign a different ridesharing vehicle (e.g., 130F) when the processorestimates that the ridesharing vehicle 1902 will arrive at the pick-uplocation 1904 later than a time originally estimated.

In some embodiments, processor 310 may be configured to track one ormore variables that impact the capacity status of the ridesharingvehicle(s) and change the capacity status and/or capacity thresholdaccordingly. For example, in one embodiment, processor 310 may track theluggage of one or more passengers that can have an effect on thecapacity status of the ridesharing vehicle and change the capacitystatus and/or capacity threshold accordingly. Luggage of one or morepassengers may be tracked in any suitable manner, such as user input,sensor input, etc. For example, in one embodiment, the passenger and/ordriver may input that he/she has a suitcase, bicycle, musicalinstrument, or other space-consuming item to transport. For furtherexample, in another embodiment, processor 310 is further configured totrack a passenger's physical condition that can have an effect on thecapacity status of the ridesharing vehicle and to change the capacitystatus and/or capacity threshold accordingly. For instance, thepassenger, driver, and/or one or more sensors may indicate that thepassenger has a wheel chair, a baby, or any other item that takes upspace, or that the passenger is a large size that will take up more thanone seat.

In some embodiments, vehicle 1902 may be directed or redirected alongthe first route 1920 when the capacity threshold is met but anadditional user is assigned to the ridesharing vehicle 1902 with apick-up location along the first route 1920. For example, in oneembodiment, the capacity threshold for vehicle 1902 may be set to 3adult passengers so no adult passengers arc assigned to sit in themiddle back seat. However, the capacity threshold may be overridden if auser (e.g., user 130A) has a pickup location (e.g., house 1904) alongthe first route 1920.

FIG. 20 illustrates a flow chart of an exemplary method 2000 fordispatching at least one ridesharing vehicle, in accordance with someembodiments of the present disclosure. For exemplary purposes only,method 2000 for dispatching at least one ridesharing vehicle isdescribed with respect to processing device 310 cooperating with memory320 to execute modules 1801-1804. In accordance with method 2000,processor 310 may receive ride requests from a plurality of users, asdescribed in detail above, at block 2002. Further, processor 310 mayreceive location information from one or more communications devicesassociated with a ridesharing vehicle at block 2004. These inputs may becollected as discussed above with respect to input data collectionmodule 1801.

Capacity status determination module 1802 may determine a capacitystatus of the ridesharing vehicle available to pick up the plurality ofusers at block 2006. For example, processor 310 may receive an inputregarding the known passenger capacity of the ridesharing vehicle (e.g.,the vehicle is an extended SUV that seats 6 passengers, a four-door carthat seats 4 passengers, etc.). Processor 310 may then receive an inputregarding the current number of passengers in the ridesharing vehicle.Based on these inputs, processor 310 may determine the capacity statusof the vehicle. The capacity status may be expressed in terms ofabsolute numbers (e.g., vehicle can accommodate 2 passengers), a binaryrepresentation (e.g., availability or no availability), or any othersuitable representation.

Vehicle routing module 1803 may send the ridesharing vehicle to pick upthe plurality of users at block 2008. Processor 310 may then querywhether the capacity status of the ridesharing vehicle is below thecapacity threshold at block 2010. Based on the result of the query atblock 2010, processor 310 may direct the ridesharing vehicle along aselected route. For example, in the illustrated embodiment, if thecapacity status of the ridesharing vehicle is not below the capacitythreshold, the ridesharing vehicle is directed along the second route1922 at block 2012. However, if the capacity status of the ridesharingvehicle is below the capacity threshold, the ridesharing vehicle isdirected along the first route 1920 at block 2014. In this way, theridesharing vehicle may be directed to a route to pick up additionalpassengers when the capacity status indicates room in the vehicle foradditional passengers or to an alternate route to drop off the existingpassengers when the capacity status indicates lack of room foradditional passengers.

Further, method 2000 includes a query as to whether a reroutingcondition has been met at block 2016. The rerouting condition may be anyfactor that renders the current route of the ridesharing vehicle more orless desirable at a given point in time. For example, the reroutingcondition may be a traffic report, identified construction, road hazard,weather alert, imminent expected demand in a nearby area, user requestfor an expedited ride, driver request to stop driving, etc. If thererouting condition is met, the ridesharing vehicle may be redirected toan alternate route at block 2020. However, if the rerouting condition isnot met, processor 310 may not make any change to the directed route atblock 2018.

For instance, in one embodiment, vehicle 1902 may be directed alongfirst route 1920 at block 2014. However, after the ride has begun,imminent demand may be predicted near library 1910 due to a readinggroup ending soon. Accordingly, vehicle 1902 may be redirected along analternate route that includes library 1910 to meet the expected imminentdemand.

Purposefully Selecting Longer Routes to Improve User Satisfaction

In the context of ridesharing, the quality of the passengers' userexperience is typically not simply a function of the arrival time,simply because there are other available transportation alternativesthat may be faster than ridesharing. Instead, a complicated combinationof factors other than the fastest time of arrival may affect thesatisfaction of a typical ridesharing passenger. In one example, asdiscussed above with reference to FIGS. 6-8, automated ridesharingdispatch system 300 may avoid using the full capacity of its vehicles inregular operation. This enhances the experience of users who mightotherwise feel cramped in vehicles at or near capacity. In anotherexample, as discussed in greater detail below, ridesharing managementsystem 100 may avoid directing the ridesharing vehicle to a fastestroute when the fastest route would violate a principle associated withexpected user satisfaction. Specifically, certain navigation maneuvers(e.g., backtracking, U-turns, traversing certain roads) can negativelyimpact the user experience, even if resulting in a faster arrival time.Therefore, as described below, ridesharing management system 100 maydetermine a driving route longer than alternative driving routes, butnevertheless determine a route that is substantially devoid ofnavigation maneuvers that negatively impact the user experience.

FIG. 21A illustrates an exemplary embodiment of a memory 2100 containingsoftware modules consistent with the present disclosure. In particular,as shown, memory 2100 may include a data capture module 2102, a trafficmodule 2104, a vehicle selection module 2106, a route determinationmodule 2108, a transmission module 2110, a database access module 2112,and a database 2114. Modules 2102, 2104, 2106, 2108, 2110, and 2112 maycontain software instructions for execution by at least one processingdevice, e.g., processor 310, included with automated ridesharingdispatch system 300. Data capture module 2102, traffic module 2104,vehicle selection module 2106, route determination module 2108,transmission module 2110, database access module 2112, and database 2114may cooperate to perform multiple operations. For example, data capturemodule 2102 may receive ride requests from a plurality of users andreceive indications of current locations of the plurality of ridesharingvehicles.

Traffic module 2104 may receive real time traffic data and enablesestimation of the durations of alternatives driving routes. Vehicleselection module 2106 may select a ridesharing vehicle to pick up theplurality of users. Route determination module 2108 may determine aroute for the selected ridesharing vehicle. Transmission module 2110 mayuse a communications interface for sending information to the pluralityof users about the pick-up location, and for sending driving directionsto the selected ridesharing vehicle based on the determined route.Database access module 2112 may interact with database 2114 which maystore a plurality of rules for determining the driving route and anyother information associated with the functions of modules 2102-2112.The plurality of rules may include a fastest route for guiding aridesharing vehicle and a rule for reducing backtracking even ininstances where backtracking would result in shorter travel time.

In some embodiments, memory 2100 may be included in, for example, memory320. Alternatively or additionally, memory 2100 may be stored in anexternal database 170 (which may also be internal to ridesharingmanagement server 150) or external storage communicatively coupled withridesharing management server 150, such as one or more database ormemory accessible over network 140. Further, in other embodiments, thecomponents of memory 2100 may be distributed in more than one server.

In some embodiments, data capture module 2102 may receive ride requestsfrom a plurality of users, and each ride request may include a startingpoint and a desired destination. A starting point may refer to a currentlocation of the user, as input by each user through an input device ofan associated user device, or as determined by a location serviceapplication installed on the user device. A desired destination mayrefer to a location where the user desires to be taken to, for example,an entrance of a shopping center. In some embodiments, data capturemodule 2102 may also receive from a plurality of communication devicesassociated with a plurality of ridesharing vehicles indications ofcurrent locations of the plurality of ridesharing vehicles. The currentlocation of the plurality of ridesharing vehicles may be determined by alocation service application installed on a driver device, adriving-control device, or by a location determination component in theridesharing management system 100, which may be a part of or separatefrom ridesharing management server 150. For example, the indications ofcurrent locations of the plurality of ridesharing vehicles may includeglobal positioning system (GPS) data generated by at least one GPScomponent associated with each ridesharing vehicle.

In some embodiments, traffic module 2104 may include instructionsconfigured to receive historical and/or real time traffic data,including information about at least one of street blockages andatypical congestion. Traffic data may include real-time traffic dataregarding a certain geographical region, and may be used to, forexample, calculate estimate time of arrival for pick-up locations. Thetraffic data may also be used for determining the driving route for aparticular ride. Real-time traffic data may be received from a real-timetraffic monitoring system, which may be integrated in or independentfrom ridesharing management system 100. In one embodiment, trafficmodule 2104 may determine the real time traffic data from informationreceived from the plurality of ridesharing vehicles. In someembodiments, traffic module 2104 may also identify an existence of anarea of traffic obstruction in a vicinity of the driving route. Trafficobstructions may include scheduled event (e.g., a parade, aninfrastructure repair, construction work, etc.) and an unscheduled event(e.g., a road closure, an accident, a public safety incident, or anyrelated environmental condition, such as a fallen tree or powerline,etc.). In another embodiment, traffic module 2104 is configured topredict traffic conditions based on historic traffic data records.

In some embodiments, vehicle selection module 2106 may select aridesharing vehicle to pick up the plurality of users. In other words,vehicle selection module 2106 may assign the plurality of users to acommon ridesharing vehicle. For example, ride service parameters may betransmitted to ridesharing management server 150 for processing the riderequest and selecting an available ridesharing vehicle based on one ormore ride service parameters. The ride service parameters may includeuser preference parameters regarding a vehicle ridesharing service, forexample, a maximum walking distance from a starting point to a pick-uplocation, a maximum walking distance from a drop-off location to adesired destination, a total maximum walking distance involved in aride, a maximum number of subsequent pick-ups, maximum delay ofarrival/detour incurred by subsequent pick-ups during a ride, and aselection whether to permit toll road usage during the ride, etc.Ridesharing management server 150 may further be configured to receiveuser input from user devices (e.g., user devices 120A-120C) as tovarious ride service parameters and may select a ridesharing vehicle topick up the user, accordingly.

In some embodiments, route determination module 2108 may determine aroute for the selected ridesharing Vehicle. The determined route mayinclude a plurality of pick-up and drop-off locations associated withthe starting points and desired destinations of the plurality of users.Consistent with the present disclosure, determining the driving routemay include selecting pick-up locations and drop-off locations for eachof the plurality of users (commonly referred to as “virtual bus stops”),and determining the path between the virtual bus stops. The determinedroute may pass between all the determined pick-up points. When selectinga virtual bus stop, route determination module 2108 may confirm that thepick-up location is within a maximum walking distance (e.g., 300 metersor less) from the starting point, and that the drop-off location iswithin a maximum walking distance (e.g., 500 meters or less) to adesired destination. The virtual bus stops for the plurality of usersand the driving route may be determined to minimize at least one of: atime duration of each user spends in the ridesharing vehicle, a timeduration each user spends waiting in the pick-up location, a distanceeach user needs to walk from the starting point to the pick-up location,a distance each user needs to walk from the drop-off location to thedesired destination, and the number of empty seats in the ridesharingvehicle.

When determining the path between two virtual bus stops, routedetermination module 2108 may determine a route for the ridesharingvehicle other than the fastest route. Specifically, route determinationmodule 2108 may determine a reduced-backtracking route. The term“reduced-backtracking route” means a route in which nonessentialdeviations from a trajectory of an average direction of the passengers'desired destinations are minimized Although an absolute non-backtrackingroute may yield the most user satisfaction, in some cases (e.g., at anexit from a highway, at a specific road formation, due to certaintraffic rules and/or conditions, etc.), selecting an absolutenon-backtracking route may not be a feasible option. Thereduced-backtracking route is a route in which unnecessary navigationmaneuvers (e.g., U-turns, three consecutive left turns, threeconsecutive right turns, and more) are avoided compared to alternativedriving routes. An example of a non-reduced-backtracking route isdepicted in FIG. 21B and an example of a reduced-backtracking route isdepicted in FIG. 21C. In some embodiments, although route determinationmodule 2108 may give more weight to the rule for reducing backtrackingthan the rule for fastest route, in some cases, driving routedetermination module 2108 may override the backtracking rule.

In some embodiments, transmission module 2110 may communicate, based oninstructions from vehicle selection module 2106, with ridesharingmanagement server 150 to send to the selected ridesharing vehicle, via acommunications interface (e.g., communications interface 360), drivingdirections according to the determined route. As discussed above,communications interface 360 may include a modem, Ethernet card, or anyother interface configured to exchange data with a network, such asnetwork 140 in FIG. 1. For example, ridesharing management server 150may include software that, when executed by a processor, providescommunications with network 140 through communications interface 360 toone or more mobile communications devices 120A-F. In some embodiments,transmission module 2110 may further send to the user, via thecommunications interface, information that causes a display of walkingdirections from a starting point to a pick-up location and from adrop-off location to a desired destination. Transmission module 2110 mayfurther send (e.g., via a communications interface) messages to thepassengers of a ridesharing vehicle when a route other than thereduced-backtracking route has been selected. The messages may appear indifferent formats, for example, a text message, an audio message, or agraphical image, which may include text. The messages may specify howmuch time each passenger is estimated to save by selecting the drivingroute other than the reduced-backtracking route.

In some embodiments, database access module 2112 may cooperate withdatabase 2114 to retrieve a plurality of rules for determining thedriving route, map information, traffic data, environmental conditiondata, and/or any associated stored data or metadata. For example,database access module 2112 may send a database query to database 2114which may be associated with database 170. Database 2114 may beconfigured to store any type of information of use to modules 2102-2112,depending on implementation-specific considerations. For example, routedetermination module 2108 may be configured to determine a route for theridesharing vehicle using a plurality of rules stored in database 2114.Route determination module 2108 may further be configured to determinethe driving route for the ridesharing vehicle using data stored indatabase 2114. The stored data may be prior-collected information.Prior-collected information may include ride request information fromusers and indications of locations of plurality of ridesharing vehiclesreceived from data capture module 2102. Prior-collected information mayalso include received real time traffic data and information providing adescription of the nature, time, and/or date of any traffic conditionsand/or environmental conditions received from traffic module 2104

In some embodiments, database 2114 may include separate databases,including, for example, a vector database, raster database, tiledatabase, viewport database, and/or a user input database, configured tostore data. The data stored in database 2114 may be received frommodules 2102-2112, ridesharing management server 150, from user devices120A-F and/or may be provided as input using data entry, data transfer,or data uploading. The data stored in the database 2114 may representmultiple data forms including, for example, general mapping andgeographic information, latitude and longitude (Lat/Lon) values, worldcoordinates, tile coordinates, pixel coordinates, Mercator and/or othermap projection data, user identifier data, driver identifier data,vehicle identifier data, device type data, viewport data, deviceorientation data, user input data, geographical scale data, and avariety of other electronic data. Database 2114 may also include, forexample, street, city, state, and country data including landmarkidentifiers and other related information. Database 2114 may alsoinclude search logs, cookies, web pages, and/or social network content,etc.

Modules 2102-2112 may be implemented in software, hardware, firmware, amix of any of those, or the like. For example, if the modules areimplemented in software, the modules may be stored in a server (e.g.,ridesharing management server 150) or distributed over a plurality ofservers. In some embodiments, any one or more of modules 2102-2112 anddata associated with database 2114, may, for example, be stored inprocessor 310 and/or located on ridesharing management server 150, whichmay include one or more processing devices. Processing devices ofridesharing management server 150 may be configured to execute theinstructions of modules 2102-2112. In some embodiments, aspects ofmodules 2102-2112 may include software, hardware, or firmwareinstructions (or a combination thereof) executable by one or moreprocessors, alone or in various combinations with each other. Forexample, modules 2102-2112 may be configured to interact with each otherand/or other modules of server 150 and/or a ridesharing managementsystem 100 to perform functions consistent with disclosed embodiments.

FIG. 21B and FIG. 21C are schematic illustrations of an example mapincluding different driving route alternatives for a ridesharing vehicle2150, according to disclosed embodiments. The map includes a pick-uplocation 2156 for a passenger with a starting point 2158 and a drop-offlocation 2152 for a passenger with a desired destination 2154. Drop-offlocation 2152 is not necessarily for the same passenger that was pickedup at pick-up location 2156. The map in FIG. 21B includes a route 2160that, based on traffic conditions, is the fastest route, while the mapin FIG. 21C includes a route 2162 that, based on traffic conditions,would take more time than route 2160 but consistent with the presentdisclosure is considered as a reduced-backtracking route.

In some embodiments, ridesharing management system 100 is configured toidentify multiple alternative route segments from pick-up location 2156to drop-off location 2152. Thereafter, ridesharing management system 100is configured to use real-time traffic data to calculate a timeestimation for each of the alternative route segments. In the exampleillustrated in FIGS. 21B and 21C, route 2160 is longer (distance wise)from route 2162, but ridesharing management system 100 estimates that itwould take 5 minutes to drive the route segment from drop-off location2152 to pick-up location 2156 using route 2160, and 8 minutes to drivethe route segment from drop-off location 2152 to pick-up location 2156using route 2162. The reason route 2160 estimated to be is faster thanroute 2162 is due to traffic congestion determined from, for example,traffic data received by ridesharing management system 100. However,consistent with the present disclosure, route 2162 is considered as areduced-backtracking route compared to route 2160 because it does nothave three consecutive left turns. In one embodiment, ridesharingmanagement system 100 may be configured to select the appropriate routefor ridesharing vehicle 2150 based on a plurality of parameters. In oneexample, when ridesharing vehicle 2150 is carrying five passengers,ridesharing management system 100 is configured to direct ridesharingvehicle 2150 via route 2162 because route 2160 has three consecutiveleft turns and it may negatively impact the user experience. In anotherexample, when ridesharing vehicle 2150 is carrying only the passengerpicked up at pick-up location 2156, ridesharing management system 100 isconfigured to direct ridesharing vehicle 2150 via route 2160, which isfaster.

With reference to the example described above. FIG. 22 depicts aflowchart of an example process 2200 used by ridesharing managementsystem 100 to select between the different route alternatives. Process2200 begins when ridesharing management system 100 receives riderequests from a plurality of users (block 2202), receives GPS locationsof the plurality of ridesharing vehicles (block 2204), and receives realtime traffic data (block 2206). Thereafter, and based on the receiveddata, ridesharing management system 100 may identify a plurality routesassociated with different travel-times (block 2207), and assign theplurality of users to ridesharing vehicle 2150. In this example,ridesharing management system 100 has identified only two relevantroutes: the fastest route (e.g., route 2160) and thereduced-backtracking route (e.g., route 2162). However, a person skilledin the art would recognize that ridesharing management system 100 mayidentify more than two route alternatives, and that process 2200specified below may be modified to enable selection between numerus ofroutes.

As mentioned above, the selection of the appropriate route forridesharing vehicle 2150 is based on different parameters. Process 2200continues when ridesharing management system 100 determines whether thenumber of passengers currently riding ridesharing vehicle 2150 is lessthan a certain threshold, e.g., two (decision block 2208). In someembodiments—in the context of process 2200, a group of passengers ridingto the same drop-off location are considered as a single passenger. Whenless than, e.g., two passengers riding ridesharing vehicle 2150,ridesharing management system 100 may direct ridesharing vehicle 2150along the fastest route (block 2218). On the other hand, when two ormore passengers are riding ridesharing vehicle 2150, ridesharingmanagement system 100 may determine whether an expected travel-timechange is greater than a backtracking threshold. In other words,ridesharing management system 100 may be configured to estimate how muchfaster the fastest route is. The backtracking threshold may bepredetermined (e.g., 10 minutes) or dynamic (e.g., 5 minutes in rushhour and 10 minutes in regular hours). For example, at 3:00 am whentraffic is typically light, passengers may mind that the ridesharingvehicle backtracks, and the backtracking threshold may be lower (e.g.,two minutes). When the expected travel-time change is greater than abacktracking threshold, ridesharing management system 100 may directridesharing vehicle 2150 along the fastest route (block 2218). In theexample above, when ridesharing vehicle 2150 carried five passengersroute 2160 was estimated to be 3 minutes faster than route 2162, andridesharing management system 100 determined to use thereduced-backtracking route. But if, for example, due to roadconstruction on street route 2160 was estimated to be 24 minutes fasterthan route 2162, ridesharing management system 100 may determine to usethe faster route.

Process 2200 continues when ridesharing management system 100 determineswhether there is an indication of imminent high demand (decision block2212). In one embodiment, the imminent high demand for ridesharingvehicles may be the result of an inclement weather condition. When thereis an indication of imminent high demand, ridesharing management system100 may direct ridesharing vehicle 2150 along the fastest route (block2218). On the other hand, when there is no an indication of imminenthigh demand, ridesharing management system 100 may determine if there isa report or other indication of an event that would affect the trafficon the reduced-backtracking route. In one embodiment, the event may be ascheduled event, for example, when the reduced-backtracking route passesnext to a school, ridesharing management system 100 may directridesharing vehicle 2150 along the fastest route near the end of theschool day. In another embodiment, the event may be an unscheduledevent, for example, when the reduced-backtracking route passes next to abuilding that is on fire, and ridesharing management system 100 maydirect ridesharing vehicle 2150 along the fastest route. Accordingly,when ridesharing management system 100 determines that the number ofpassengers currently riding ridesharing vehicle 2150 is greater thantwo, the expected travel-time change may be less than a backtrackingthreshold, and when there is no an indication of imminent high demandand there is no report or other indication of an event that would affectthe traffic on the reduced-backtracking route, the system may directridesharing vehicle 2150 along the reduce-backtracking route.

Reference is now made to FIG. 23, which depicts an exemplary method 2300for managing a fleet of ridesharing vehicles consistent with the presentdisclosure. In one embodiment, the steps of method 2300 may be performedby automated ridesharing dispatch system 300. In the followingdescription, reference is made to certain components of ridesharingmanagement server 150 for purposes of illustration. It will beappreciated, however, that other implementations are possible and thatother components may be utilized to implement the exemplary method. Itwill be readily appreciated that the illustrated method can be alteredto modify the order of steps, delete steps, or further includeadditional steps.

At step 2302, a communications interface (e.g., communications interface360) may receive ride requests from a plurality of users. Consistentwith the present disclosure, each ride request may include a startingpoint and a desired destination. As mentioned above, the starting pointmay refer to a current location of the user, as input by the userthrough an associated user device, or as determined by a locationservice application installed on the associated user device. In someembodiments, the starting point may be a location different from thecurrent location of the user, for example, a location where the userwill subsequently arrive at (e.g., entrance of a building). A desireddestination may refer to a location where the user requests to be takento. In another embodiment, each ride request may include additionalinformation, for example, information identifying the user, a selectionof a type ridesharing service, an indication of a maximum walkingdistance, etc.

At step 2304, the communications interface may receive from a pluralityof communication devices associated with a plurality of ridesharingvehicles, indications of current locations of the plurality ofridesharing vehicles. Consistent with the present disclosure, theindications of the current locations of the plurality of ridesharingvehicles may include global positioning system (GPS) data generated byat least one GPS component associated with each ridesharing vehicle. Inone example, the plurality of communication devices may include mobiledevices such as tablets or smartphones that belong to the drivers of theridesharing vehicles. In another example, the plurality of ridesharingvehicles includes multiple smart vehicles and each communication devicemay be a component of a smart vehicle. The term “smart vehicles” refersto vehicles (autonomously and/or manually-driven) with computingresources, location determination components, and communication devices.A smart vehicle may communicate with ridesharing management system 100independently to the driver.

At step 2306, a processing device (e.g., processor 310) may accessmemory database 170) configured to store a plurality of rules includinga rule to select a fastest route for guiding a ridesharing vehicle and arule for reducing backtracking, even in instances where backtrackingwould result in a shorter travel time. In addition to the fastest routerule and the reduced-backtracking rule, the memory is further configuredto store additional rules for determining the driving route for theridesharing vehicle. For example, a rule to avoid specific roads, a ruleto minimize a time duration in which each assigned user spends in theridesharing vehicle, a rule to minimize a time duration in which eachassigned user spends waiting, a rule to minimize a distance eachassigned user needs to walk from the starting point to the pick-uplocation, a rule to minimize a distance each assigned user needs to walkfrom the drop-off location to the desired destination, and a rule tominimize the number of empty seats in the ridesharing vehicle.

At step 2308, the processing device may assign the plurality of users toa common ridesharing vehicle (e.g., ridesharing vehicle 2150).Consistent with the present disclosure, the processing device is furtherconfigured to assign a user to the ridesharing vehicle based on at leastsome of the following parameters: a location of the ridesharing vehicle,a driving direction of the ridesharing vehicle, a driving route of theridesharing vehicle, a number of passengers riding the ridesharingvehicle, a number of users assigned to the ridesharing vehicle andscheduled to be picked up, the virtual bus stops that the ridesharingvehicle is scheduled to stop, the desired destinations of all the usersassigned to the ridesharing vehicle, real time traffic data, the user'sstarting point, the user's desired destination, the user's personalpreferences, and the type of service the user selected.

At step 2310, the processing device may use the stored plurality ofrules to determine a route for the ridesharing vehicle other than thefastest route. The determined route including a plurality of pick-up anddrop-off locations associated with the starting points and desireddestinations of the plurality of users. Consistent with the presentdisclosure, the processing device may select the determined route toaccount for the rule for reducing backtracking. In one embodiment,applying the rule for reducing backtracking means routing theridesharing, vehicle in a manner avoiding a trajectory opposite to anaverage direction of the plurality of users' desired destinations. Forexample, in some instances, the system may avoid a trajectory of 120-180degrees away from the user's desired destination. In another embodiment,applying the rule for reducing backtracking means routing theridesharing vehicle in a manner avoiding three consecutive left turns.In another embodiment, applying the rule for reducing backtracking meansrouting the ridesharing vehicle in a manner avoiding three consecutiveright turns. In another embodiment, applying the rule for reducingbacktracking means routing the ridesharing vehicle in a manner reducingU-turns. In another embodiment, applying the rule for reducingbacktracking means routing the ridesharing vehicle in a manner reducingunnecessary navigation maneuvers. In another embodiment, applying therule for reducing backtracking may include routing the ridesharingvehicle in a manner that takes into consideration a combination ofduration and distance.

In some embodiments, the processing device may receive real time trafficdata and may calculate an expected travel-time change associated withusers currently riding in the ridesharing vehicle when the ridesharingvehicle is directed along a route with backtracking as compared to aroute with reduced backtracking. In other words, the processing devicemay estimate how much time the passengers will save if the ridesharingvehicle would take the driving route with backtracking. In oneembodiment, the expected travel-time change may be calculated separatelyfor each of the users currently riding the ridesharing vehicle.Alternatively, the expected travel-time change may be calculatedcollectively for the users currently riding the ridesharing vehicle.Consistent with the present disclosure, the processing device may befurther configured to override the backtracking rule when the receivedtraffic data is indicative of at least one of street blockages andatypical congestion. For example, the traffic data may be indicative ofa road closure, a parade, an accident, a public safety incident, and aninfrastructure repair. Additionally, the processing device may befurther configured to override the backtracking rule in response to areceived indication of imminent high demand for rides. Additionally, theprocessing device may be further configured to override the backtrackingrule when an expected travel-time change is higher than a backtrackingthreshold. As described above, the value of the backtracking thresholdmay be dynamic and may be determined based on at least one of a time ofday and a type of users currently riding the ridesharing vehicle (e.g.,regular users, VIP users, students, and more).

At step 2312, the processing device may direct the ridesharing vehiclealong the determined route other than the fastest route in order toreduce backtracking. In the example above, ridesharing vehicle 2150 maybe directed via route 2162 and not 2160. However, as discussed above,consistent with disclosed embodiments the processing device may befurther configured to override the backtracking rule. In one scenario,the processing device may determine an updated route along which todirect the ridesharing vehicle, and to change at least one drop-offlocation of the plurality of users after determining the updated route.In a similar scenario, the processing device may be further configuredto override the backtracking rule, determine an updated route alongwhich to direct the ridesharing vehicle, and to reassign a userscheduled to be picked up by the ridesharing vehicle to anotherridesharing vehicle. Typically, these scenarios happen when one of theparameter described above has changed. For example, with reference toFIGS. 21B and 21C, the following scenario may happen, processing devicemay receive traffic information that an accident occurred on aparticular street and that it would take 18 minutes to drive fromdrop-off location 2152 to pick-up location 2156 using route 2162(instead on 8 minutes). Accordingly, the processing device may overridethe backtracking rule and either change at least one drop-off locationof the plurality of users after determining the updated route orreassign a user scheduled to be picked up by the ridesharing vehicle toanother ridesharing vehicle. In sonic embodiments, the processing devicemay receive at least one additional ride request from at least oneadditional user and change the determined route to pick-up at the leastone additional user.

Route Planning Based on Environmental Conditions

In some embodiments, ridesharing management server 150 may receive aride request from, for example, user 130A sent through user device 120A.The ride request may include a starting point and a desired destinationof the user. When processing such rides requests in order to timelynavigate the user from the starting point to the desired destination,the system may need to take into account traffic or other environmentalconditions. For example, existing systems may not be equipped todetermine an optimum route that avoids traffic or environmentalconditions. Moreover, although existing systems may provide a choice toa user of different route options, given the increasing frequency ofenvironmental disturbances, may nevertheless fail to provide real-timeroute planning based on traffic or environmental conditions. Presentlydisclosed embodiments, on the other hand, address this technical problemby providing route planning based on received user ride requests anddetected or anticipated environmental conditions.

For example, in one embodiment, ridesharing management server 150 mayreceive real time traffic data, including information about at least oneof street blockages and atypical congestion from a plurality of driverdevices (e.g., driver devices 120D and 120E) associated with drivers(e.g., drivers 130D and 130E) operating vehicles. Ridesharing managementserver 150 may be configured to send, based on the real time trafficdata, ride service assignments (e.g., including pick-up and drop-offlocation information) to the plurality of driver devices associated withthe drivers, and/or a driving-control device (e.g., driving-controldevice 120F) associated with an autonomous vehicle (e.g., autonomousvehicle 130F), to substantially avoid the street blockages and atypicalcongestion.

In some embodiments, ridesharing management server 150 may identify achange in the area of traffic obstruction, based on detected trafficdata and related environmental conditions, and may send updated drivingdirections to a user, driver device and/or a driving-control deviceassociated with an autonomous vehicle to substantially avoid the area oftraffic obstruction. Ridesharing management server 150 may determine analternative pick-up location to accommodate the change in the area oftraffic obstruction. Ridesharing management server 150 may send to theuser information about the alternative pick-up location and update thedriving directions to accommodate the change in the area of trafficobstruction.

In some examples, ridesharing management server 150 may also predict anarea that may have traffic obstruction in the near future, based ontraffic data and environmental conditions stored, for example, indatabase 170, and may determine pick-up and drop-off locations and sendcorresponding walking instructions to one or more users sending riderequests to ridesharing management server 150. A user may then followthe walking instructions to move to a pick-up location that avoids theanticipated traffic obstruction.

As discussed above, user devices 120A-120C, driver devices 120D and120E, and driving-control device 120F may respectively be installed witha user side ridesharing application, and a corresponding driver sideridesharing application. Mobile communications device 200 may beinstalled with the user side ridesharing application, and thecorresponding driver side ridesharing application, and/or other softwareto perform one or disclosed embodiments, such as on mobilecommunications devices 120A-120F. Mobile communications device 200 mayretrieve GPS/navigation instructions 268 from memory 250 and mayfacilitate GPS and navigation-related processes or routes associatedwith drivers 130D and 130E in communication with ridesharing managementserver 150. Ridesharing management server 150 may receive real timetraffic data including any traffic obstruction in a vicinity of a user'sstarting point, select a vehicle-for-hire to pick up the user, identifya pick-up location, send to user 130A-C information about the pick-uplocation, and send to driver devices 120D and 120E associated withdrivers 130D and 130E, and driving-control device 120F drivingdirections to the pick-up location, as described in greater detailbelow.

In some embodiments, ridesharing management server 150 may transmitinformation to user device 120A-C, which may be, for example, asmartphone or tablet having a dedicated application installed therein. Agraphical user interface (GUI) including a plurality of user-adjustablefeature user side or driver-side ridesharing application settings may beincluded on a display of mobile communications devices 120A-120C tovisibly output information to one or more users 130A-C and drivers 130Dand 130E.

FIG. 24 illustrates an exemplary embodiment of a memory 2400 containingsoftware modules consistent with the present disclosure. In particular,as shown, memory 2400 may include a data capture module 2402, a trafficmodule 2404, a vehicle and pick-up location selection module 2406, atransmission module 2408, a database access module 2410, and a database2412. Modules 2402, 2404, 2406, 2408, and 2410 may contain softwareinstructions for execution by at least one processing device, e.g.,processor 310, included with automated ridesharing dispatch system 300.Data capture module 2402, traffic module 2404, vehicle and pick-uplocation selection module 2406, transmission module 2408, databaseaccess module 2410, and database 2412 may cooperate to perform multipleoperations. For example, data capture module 2402 may receive a riderequest from a user and receive indications of current locations of theplurality of vehicles-for-hire. Traffic module 2404 may receive realtime traffic data and identify an existence of an area of trafficobstruction. Vehicle and pick-up location selection module 2406 mayselect a vehicle-for-hire to pick up the user and identify a pick-uplocation. Transmission module 2408 may send to the user, via acommunications interface, information about the pick-up location, andmay send to the selected vehicle-for-hire, via a communicationsinterface, driving directions to the pick-up location. Database accessmodule 2410 may interact with database 2412 which may store anyinformation associated with the functions of modules 2402-2408,

In some embodiments, memory 2400 may be included in, for example, memory320 storing programs 330 including, for example, server app(s) 332,operating system 334, and data 340, and a communications interface 360discussed above. Alternatively or additionally, memory 2400 may bestored in an external database 170 (which may also be internal toridesharing management server 150) or external storage communicativelycoupled with ridesharing management server 150, such as one or moredatabase or memory accessible over network 140. Further, in otherembodiments, the components of memory 2400 may be distributed in morethan one server.

In some embodiments, data capture module 2402 may receive a ride requestfrom a user, and the ride request may include a starting point and adesired destination. A starting point may refer to a current location ofthe user, as input by the user through an input device of an associateduser device, or as determined by a location service applicationinstalled on the user device. In some embodiments, the starting pointmay be a location different from the current location of the user, forexample, a location where the user will subsequently arrive at (e.g., anentrance of a building after walking a predetermined distance). Adesired destination may refer to a location where the user requests tobe taken to, including for example, a drop off-point located at or neara particular destination point (e.g., an entrance of a differentbuilding). In some embodiments, data capture module 2402 may alsoreceive from a plurality of communication devices associated with aplurality of vehicles-for-hire indications of current locations of theplurality of vehicles-for-hire. The current location of the plurality ofvehicles-for-hire may be determined by a location service applicationinstalled on a driver device, a driving-control device, or by a locationdetermination component in the ridesharing management system 100, whichmay be a part of or separate from ridesharing management server 150.

In some embodiments, data capture module 2402 may also include softwareinstructions for categorizing data obtained by ridesharing managementserver 150 (and obtained from other servers and/or user devices 120A-Cover network 140) into a plurality of categories including, for example,ride request route information and vehicle-for-hire locations. Datareceived may include audio and image data, captured, by, for example, animage sensor or a microphone associated with vehicle-for-hires and aplurality of user devices. Data received from ridesharing managementserver 150 may also include GPS data and/or other user 130A-C or driver130D-E device identifiers related to mobile communication devices120A-F. In some embodiments, image data, audio data, GPS data, and user130A-C or driver 130D-E data may be preprocessed by data capture module2402. Preprocessing may include, for example, sorting, filtering, and orautomatically storing or categorizing data relating to ride requests,route information, and/or vehicle-for-hire locations in database 170.

In some embodiments, traffic module 2404 may include instructionsconfigured to receive historical and/or real time traffic data,including information about at least one of street blockages andatypical congestion. Traffic data may include real-time traffic dataregarding a certain geographical region, and may be used to, forexample, calculate estimate pick-up and drop-off times, and determine anoptimal route for a particular ride. Real-time traffic data may bereceived from a real-time traffic monitoring system, which may beintegrated in or independent from ridesharing management system 100.Traffic module 2404 may determine real time traffic data informationreceived from the plurality of communication devices associated with theplurality of vehicles-for-hire. In some embodiments, traffic module 2404may also identify an existence of an area of traffic obstruction in avicinity of the user's starting point. Traffic obstructions may includea road closure, a parade, an accident, a public safety incident, aninfrastructure repair, a car accident, construction work, or any relatedenvironmental condition, such as a fallen tree or powerline. The area oftraffic obstruction may be a region where traffic flow is slower than inan adjacent region. Other types of obstructions contemplated by one ofordinary skill in the art are consistent with the disclosed embodiments.

In some embodiments, vehicle and pick-up location selection module 2406may select a vehicle-for-hire to pick up the user. For example, rideservice parameters may be transmitted to ridesharing management server150 for processing the request and selecting an availablevehicle-for-hire based on the ride service parameters. Ride serviceparameters may include user preference parameters regarding a vehicleridesharing service, for example, a maximum walking distance from astarting point to a pick-up location, a maximum walking distance from adrop-off location to a desired destination, a total maximum walkingdistance involved in a ride, a maximum number of subsequent pick-ups,maximum delay of arrival/detour incurred by subsequent pick-ups during aride, and a selection whether to permit toll road usage during the ride,etc. Ridesharing management server 150 may further be configured toreceive user input from user devices (e.g., user devices 120A-120C) asto various ride service parameters and may select a vehicle-for-hire topick up the user, accordingly.

In some embodiments, vehicle and pick-up location selection module 2406may also identify a pick-up location, which may be remote from theuser's starting point, and peripheral to the area of trafficobstruction. Vehicle and pick-up location selection module 2406 mayselect the pick-up location such that a path from a current location ofthe selected vehicle-for-hire to the pick-up location avoids the area oftraffic obstruction. For example, a ride request may be associated witha maximum walking distance (e.g., 300 meters) from a starting point to apick-up location that is remote from the user's starting point, asdiscussed above. When selecting an available vehicle to pick up theuser, vehicle and pick-up location selection module 2406 may alsoinclude in the assignment an assigned pick-up location within themaximum walking distance (e.g., 300 meters or less from the startingpoint). Similarly, a ride request may be associated with a maximumwalking distance (e.g., 500 meters) from a drop-off location to adesired destination. When selecting an available vehicle to pick up theuser, vehicle and pick-up location selection module 2406 may alsoinclude in the assignment an assigned drop-off location within themaximum walking distance (e.g., 500 meters or less from the desireddestination). For requests associated with a maximum total walkingdistance relative to both the pick-up location and the drop-offlocation(e.g., a user is willing to walk up to a combined distance ofone kilometer to both reach the pick-up location and to reach a desireddestination from the drop-off location), when assigning an availablevehicle to pick up the user, vehicle and pick-up location selectionmodule 2406 may select an assigned pick-up location and an assigneddrop-off location accordingly (e.g., the combined distance from theuser's starting point to the pick-up location and from the drop-offlocation to the desired destination is equal to or less than onekilometer).

In some embodiments, transmission module 2408 may communicate, based oninstructions from vehicle and pick-up location selection module 2406,with ridesharing management server 150 to send to the user, via acommunications interface (e.g., communications interface 360),information about the pick-up location. As discussed above,communications interface 360 may include a modem, Ethernet card, or anyother interface configured to exchange data with a network, such asnetwork 140 in FIG. 1. For example, ridesharing management server 150may include software that, when executed by a processor, providescommunications with network 140 through communications interface 360 toone or more mobile communications devices 120A-F. In some embodiments,transmission module 2408 may also send to the selected vehicle-for-hire,via the communications interface, driving directions to the pick-uplocation. The transmitted driving directions may substantially avoid anarea of traffic or other obstruction or environmental condition. In someembodiments, transmission module 2408 may further send to the user, viathe communications interface, walking directions from the drop-offlocation to the desired destination.

In some embodiments, transmission module 2408 may also communicate withridesharing management server 150 to send via a communications interfacea first message to user device 120A to cause an indication of acalculated estimated pick-up time to appear on a display of user device120A. Transmission module 2408 may also send a second message to userdevice 120A walking directions from the drop-off location to the desireddestination. Transmission module 2408 may further send via acommunications interface in a message to the selected vehicle-for-hiredriving directions and an estimated time of travel to the pick-uplocation. The messages may appear in different formats, for example, atext message including an estimated pick-up time, an audio message, or agraphical image, which may include text. Transmission module 2408 mayalso communicate confirmation messages and notification and/or alertsbased on detected changes in real-time traffic data. Transmission module2408 may also transmit selected maps for mobile devices 120A-F inaccordance with instructions determined by vehicle and pick-up locationselection module 2406.

In some embodiments, database access module 2410 may cooperate withdatabase 2412 to retrieve map information, traffic data, environmentalcondition data, and/or any associated stored data or metadata. Forexample, database access module 2410 may send a database query todatabase 2412 which may be associated with database 170. Database 2412may include a map vector-based database or a map raster-based database,and database access module 2410 may be configured to extract a map imagefrom a larger pre-assembled map image, which may be delivered to, forexample, user device 120A-C or driver device 120D-F for display. In someembodiments, instead of a vector-based or raster-based system, atile-based system may be implemented from database 2412. For example,database access module 2410 may instruct processor 310 to send a requestfor map data to an external map tile server, and mobile devices 120A-Fmay receive a set of map tiles corresponding to a ride request. In otherembodiments, database access module 2410 may instruct a tile makerprogram module to divide raster images into a plurality of discrete maptiles from a painter library or rich map engine library that iscommercially available. Database access module 2410 may instructprocessor 310 to compile a received set of cut map tiles in a grid,position the tile grid with respect to a clipping shape, and may outputthe grid as a single map as part of a user or driver side ridesharingapplication displayed within a GUI or web browser of mobile devices120A-F. Database access module 2410 may select map information inaccordance with GPS data and determined pick-up and drop-off locationsspecified by user 120A-C, vehicle-for-hire driver 130D-E locations, andidentified locations of traffic obstructions.

Database 2412 may be configured to store any type of information of useto modules 2402-2410, depending on implementation-specificconsiderations. For example, in embodiments in which traffic module 2404is configured to provide information about traffic conditions to thedriver of a vehicle-for-hire, database 2412 may also retrieve storedprior-collected information. Prior-collected information may includeride request information from users and indications of locations ofplurality of vehicles-for-hire received from data capture module 2402.Prior-collected information may also include received real time trafficdata and information providing a description of the nature, time, and/ordate of any traffic conditions and/or environmental conditions receivedfrom traffic module 2404. The description may include words and/orimages (e.g., photographs, icons, symbols, etc.) representing theconditions. In some embodiments, database 2412 may store one or moreimages received from traffic module 2402 that include traffic dataincluding congestion and/or any environmental conditions.Prior-collected information may also include pick-up locations receivedfrom vehicle and pick-up location selection module 2406 or anytransmitted information received from transmission module 2410.

In some embodiments, database 2412 may include separate databases,including, for example, a vector database, raster database, tiledatabase, viewport database, and/or a user input database, configured tostore data. The data stored in database 2412 may be received frommodules 2402-2410, ridesharing management server 150, from user devices120A-F and/or may be provided as input using data entry, data transfer,or data uploading. The data stored in the database 2412 may representmultiple data forms including, for example, general mapping andgeographic information, latitude and longitude (Lat/Lon) values, worldcoordinates, tile coordinates, pixel coordinates, Mercator and/or othermap projection data, user identifier data, driver identifier data,vehicle identifier data, device type data, viewport data, deviceorientation data, user input data, geographical scale data, and avariety of other electronic data. Database 2412 may also include, forexample, street, city, state, and country data including landmarkidentifiers and other related information. Database 2412 may alsoinclude search logs, cookies, web pages, and/or social network content,etc.

Modules 2402-2410 may be implemented in software, hardware, firmware, amix of any of those, or the like. For example, if the modules areimplemented in software, the modules may be stored in a server (e.g.,ridesharing management server 150) or distributed over a plurality ofservers. In sonic embodiments, any one or more of modules 2402-2410 anddata associated with database 2412, may, for example, be stored inprocessor 310 and/or located on ridesharing management server 150, whichmay include one or more processing devices. Processing devices ofridesharing management server 150 may be configured to execute theinstructions of modules 2402-2410. In some embodiments, aspects ofmodules 2402-2410 may include software, hardware, or firmwareinstructions (or a combination thereof) executable by one or moreprocessors, alone or in various combinations with each other. Forexample, modules 2402-2410 may be configured to interact with each otherand/or other modules of server 150 and/or a system 100 to performfunctions consistent with disclosed embodiments.

FIG. 25 is a schematic illustration of an example of a map 2500including map information used for ridesharing purposes according to adisclosed embodiment. Map 2500 may include a map implemented onuser-side and/or drive-side ridesharing applications. In the exampleshown in FIG. 25, map 2500 includes a map of the city of Las Vegasincluding McCann Airport, Las Vegas Blvd., and Downtown Las Vegas. Map2500 may include a user 2502 located, for example, on Las Vegas Blvd.near McCann. Airport and a traffic obstruction 2504 located nearby onLas Vegas Blvd. prior to the intersection of Flamingo Rd. Trafficobstruction 2504 may be representative of traffic-based environmentalconditions including, for example, construction work, traffic, and/orboth. In some embodiments, other environmental conditions (not shown)such as at least one of a road closure, a parade, an accident, a publicsafety incident, and an infrastructure repair may be included as iconsor graphics displayed on map 2500 as alternatives to or in addition totraffic obstruction 2504. Further, although the indication of thetraffic obstruction shown in FIG. 25 is an icon, in some embodiments, inaddition to the icon or as an alternative to the icon, the indication ofthe traffic obstruction may include words describing the trafficobstruction and/or images of the traffic obstruction.

Map 2500 may be displayed as part of a GUI visible on, for example,mobile devices 120A-F. In the example shown in FIG. 25, user 2502 maysend a request for pick up at a present location along Las Vegas Blvd.near McCarron Airport and may request to be dropped off at a requesteddestination, such as on Las Vegas Blvd. at the intersection of DesertInn Rd. Alternatively, as another example, user 2502 may request to bedropped off at another destination, such as Downtown Las Vegas.Consistent with the disclosure, different user pick-up points anddifferent destination points may be inputted by user 2052 operating userdevice 120A-C and sent to ridesharing management server 150. In someembodiments, a plurality of vehicles for hire located in the vicinity ofuser 2502 may be displayed and/or updated in real-time on map 2500. Forexample, map 2500 shows a vehicle 2508 located on Sahara Ave. at thetime user 2502 submits a ride request. In some embodiments, data relatedto distances of one or more vehicles-for-hire to user 2502 and/orestimated times to reach user 2502 may be displayed and/or updated inreal-time on map 2500 according to preferences of user 2502. Inaddition, map 2500 may be zoomed-in or zoomed-out based on preferencesof user 2502,

In some embodiments, map 2500 may identify a user location, allow a userto subsequently identify a desired pick-up or drop-off point forridesharing, and/or identify a traffic or environmental condition inrelation to the pick-up and drop off points so as to avoid theobstruction during ridesharing. Additionally, map 2500 may includebuttons (not shown) for user input to facilitate a pick-up request basedon a user's location. For example, based on user 2502 selection of abutton, a prompt to a user may ask for permission to access the currentGPS location of smartphone 120A. In response to user approval enablingaccess to a current GPS location, processor 310 may then zoom thedisplayed map 2500 image to fit the map data to the boundaries ofsmartphone 120A viewport, and/or may surround the map data around anorigin aligned with current geographic location of smartphone 120A. Insome embodiments, selection of buttons may provide a dialogue box to auser to allow for entry of text indicating a desired zip code (e.g.,88901) or a geographic area (e.g., Las Vegas,), or a current location orlandmark (e.g., McCarron Airport) and an intended destination address(e.g., Downtown Las Vegas). Further, the user may then identify adesired pick-up and/or drop off point within the confines of thedisplayed map 2500 image by making selections (e.g., selections made ona touch screen) and/or through user input (e.g., spoken commands, text,etc.).

In some embodiments, at least one processor (e.g., processor 310) may beconfigured to receive information from an external source, predict anarea that will have traffic obstruction in the near future, and use thepredicted area in determining the pick-up location. For example, in someembodiments, the viewport of smartphone 120A may be configured toimplement maps from other sources available over the network or fromanother digital mapping software application. GUIs may include displayof a web browser including a search tool bar (not shown) configured toreceive and process search queries related to displayed map datareceived from an external source or other sources available over thenetwork. The search tool bar may allow for user 2502 to search for adisplayed map area for one or more landmarks (e.g., Caesar's Palace),including but not limited to hotels, gas stations, etc. In someembodiments, a scale may be displayed on map 2500 and may indicatedistance between streets and landmarks. In some embodiments, a requestfor map data may include a request based on a selection of button to usethe current location of smartphone 120A, as discussed above. The requestfor map data may further include a request for at least one of a roadmap, satellite map, hybrid map, and terrain type map formats.

As discussed above, selection module 2404 may determine one or moreroutes based on a ride request, including preferred pick-up and drop-offlocations, and detected traffic and/or environmental conditions in thevicinity. For example, selection module 2404 may determine a directroute for navigating vehicle 2508 to user 2502 by traveling on SaharaAve. to Las Vegas Blvd, and proceeding to McCarran Airport. However,when taking into account traffic obstruction 2504, consistent withdisclosed embodiments, ridesharing management sever 150 may insteaddetermine a different pick-up point in order to avoid trafficobstruction 2504.

For example, ridesharing management server 150 may determine a differentpick-up point completely remote from the user's starting point, which inthis example, may be peripheral to the area of traffic obstruction 2504.In some embodiments, transmission module 2406 may instruct ridesharingmanagement server 150 to send to user 2502, via the GUI communicationsinterface of map 2500, information about the pick-up location, which maybe represented by icon 2506 (e.g., an “X” marking the pick-up location)on map 2500. Icon 2506 designates a location that is within walkingdistance to the current location of user 2502. As shown, the pick-uplocation at icon 2506 is past traffic obstruction 2504. Walkinginstructions to the pick-up point may be provided. Ridesharingmanagement server 150 may also send driver instructions along route 2514to avoid traffic so as to pick up user 2502 in a more expedited fashion.Further, as discussed earlier, ridesharing management server 150 maydetermine the pick-up point taking into account a maximum walkingdistance according to a preference of user 2502.

In some embodiments, vehicle and pick-up location selection module 2406may select a vehicle-for-hire in accordance with real time traffic datareceived at traffic module 2404. For example, if a vehicle has a closestroute to a desired destination, but has to back track to avoid a trafficor environmental condition, vehicle and pick-up location selectionmodule 2406 may instead select another vehicle, and have it take alonger route. Alternatively, vehicle and pick-up location selectionmodule 2406 may select a vehicle based on other service parameters,including for example, a maximum walking distance from the startingpoint to a pick-up location, a maximum walking distance from a drop-offlocation to a desired destination, a total maximum walking distanceinvolved in a ride, a maximum number of subsequent pick-ups, maximumdelay of arrival/detour incurred by subsequent pick-ups during a ride,and a selection whether to permit toll road usage during the ride, asdiscussed above.

FIG. 26 is a flowchart of an example of a method 2600 for directing avehicle-for-hire and a prospective passenger to a remote pick-uplocation to avoid traffic congestion. Steps of method 2600 may beperformed by one or more processors of ridesharing management server 150and/or memory 320 and memory modules 2400. Further, as discussedearlier, although the following example is in the context of trafficcongestion, the disclosed embodiments may determine a pick-up locationto avoid any traffic and/or environmental condition.

At step 2610, data capture module 2402 may receive a ride request from auser 130A-C. The ride request may include a starting point and a desireddestination. For example, data capture module 2402 may receive a riderequest from user 130A-C including a starting point (e.g., Las VegasBlvd. at McCarran Airport) and a desired destination (e.g., Downtown LasVegas) and current GPS locations of a plurality of vehicles-for-hire.Data received from ridesharing management server 150 may include GPSdata and/or other user 130A-C or driver 130D-E device identifiersrelated to mobile communication devices 120A-F. In some embodiments,pick-up locations, drop-off locations, associated GPS data, and user130A-C or driver 130D-E data may be processed by data capture module2402.

At step 2612, data capture module 2402 may receive current locations ofvehicles of a plurality of vehicles-for-hire. The current locations ofthe plurality of vehicles-for-hire may be determined by a locationservice application installed on a driver device, a driving-controldevice, or by a location determination component in the ridesharingmanagement system 100, which may be a part of or separate fromridesharing management server 150.

At step 2614, traffic module 2404 may receive real-time traffic data andmay identify an area of traffic obstruction 2504. Traffic data mayinclude real-time traffic data regarding a certain geographical region,and may be used to, for example, calculate estimate pick-up and drop-offtimes, and determine an optimal route for a particular ride. Forexample, real-time traffic data may be received from a real-time trafficmonitoring system, which may be integrated in or independent fromridesharing management system 100. Based on detection of atypicalcongestion, traffic module 2404 may include software instructions forreceiving data indicative of an area of a traffic obstruction frontridesharing management server 150.

In some embodiments, image data, audio data, GPS data, and/or user datamay be processed and/or analyzed by traffic module 2404 in order toidentify the traffic obstruction.

At step 2616, vehicle and pick-up location selection module 2406 mayselect a vehicle-for-hire to pick up the user. For example, ride serviceparameters may be transmitted to ridesharing management server 150 forprocessing the request and selection of an available vehicle-for-hirebased on the ride service parameters, as discussed above. Ridesharingmanagement server 150 may further be configured to receive user inputfrom user devices 120A-120C as to various ride service parameters andmay select a vehicle-for-hire to pick up the user according to thespecified parameters. Ridesharing management server 150 may communicatewith devices associated with one or more of drivers 130D-E and aplurality of vehicle-for-hires across network 140, and may select avehicle closest to the pick-up point of the user and/or located on aroute that avoids the traffic obstruction. Other parameters of vehicleselection may be considered, including, for example, the location andavailability of other vehicles-for-hire in the vicinity of the user, andincluding, for example, that other users may be simultaneously sendingpick-up requests in a location proximate to user. Additionally, in someembodiments, ridesharing management server 150 may assign a plurality ofusers to concurrently share a vehicle-for-hire, and/or may determinediffering pick-up locations and differing drop-off locations for theplurality of users.

At step 2618, vehicle and pick-up location selection module 2406 mayidentify a pick-up or drop-off location apart from the user's startingpoint. For example, vehicle and pick-up location selection module 2406may identify a pick-up location that is remote from the user's startingpoint and peripheral to the area of the traffic obstruction. In someembodiments, a ride request may be associated with a maximum walkingdistance (e.g., 300 meters, 500 meters, etc.) from a starting point to apick-up location that is remote from the user's starting point, asdiscussed above. In some embodiments, a ride request may be associatedwith a walking distance which is higher than maximum thresholds in casea close point cannot be found due to one or more conditions of thecongested area. The pick-up location may or may not be inputted by theuser or may be determined based on avoiding the traffic obstruction. Insome embodiments, the pick-up location may be selected in an areacurrently walkable from a determined GPS position of the user's currentlocation when sending a request for pick-up. For example, vehicle andpick-up location selection module 2406 may identify a pick-up locationalong a route that avoids the traffic obstruction.

At step 2620, transmission module 2408 may send to the user informationabout the pick-up location. For example, server 150 may transmit to userdevice 120A-C information relating to the pick-up location which may bedisplayed as an icon on a map, as discussed above. As pail of thedisplayed information, walking directions to the pick-up location may beprovided in visual, textual, and/or audio form so that the user caneasily find the pick-up point. Consistent with this disclosure,transmission module 2408 may communicate with ridesharing managementserver 150 to send a first message to a user device 120A-C to provideinformation about pick-up location to display of user device 120A-C. Themessage may appear in different formats, for example, a text messageincluding the estimated pick-up time, an audio message, or an image.Transmission module 2408 may communicate confirmation messages andnotification and/or alerts based on detected changes in real-timetraffic data, which may then change the pick-up and/or drop-offlocations for the user to alternative locations. For example,ridesharing management server 150 may send information about the pick-uplocation to the user including walking directions to a location that is,for example, at least one block away from the user's starting point.Further, ridesharing management server 150 nay select the pick-uplocation and the driving directions so that the user arrives at thepick-up location before arrival of the vehicle-for-hire.

At step 2622, transmission module 2408 may send to the selectedvehicle-for-hire driving directions to the pick-up-location. Forexample, ridesharing management server 150 may transmit to a vehicle forhire using any number of electronic devices 120 information relating tothe pick-up location. The information relating to the pick-up locationmay be displayed as an icon on a map, as discussed above. As part of thedisplayed information, driving directions to the pick-up location mayalso be provided in visual, textual, and/or audio form so that thedriver may easily drive to the pick-up point. Consistent with thisdisclosure, transmission module 2408 may be configured to send, based onreal time traffic data, ride service assignments (for example, includingpick-up and drop-off location information) to the plurality of driverdevices 120D and 120E associated with drivers 130D and 130E and/ordriving-control device 120F, to substantially avoid the trafficobstruction.

Detecting the Number of Vehicle Passengers

In sonic embodiments, ridesharing management server 150 may receive riderequest for a plurality of users and schedule more than one user toshare the same vehicle-for-hire. In some situations, existing systemsmay encounter the technical problem of how to process the ride requestswhile taking into vehicle occupancy levels in order to transportpassengers without exceeding a capacity of a ridesharing vehicle. Forexample, existing systems may have difficulty accurately detecting achanging occupancy of a vehicle-for-hire as it travels from one locationto another, at which passengers may enter and/or exit. Some systems mayprovide different vehicle types to account for different occupancies,given that the number of vehicle passengers may unpredictably change,but fail to provide real-time detection of ridesharing vehiclepassengers. Presently disclosed embodiments, on the other hand, addressthis problem by providing capacity information to a server based ondetected sensor information.

For example, in some embodiments, ridesharing management server 150 mayreceive from at least one sensor associated with ridesharing vehiclesoperated by drivers 130D and 130E, and/or driving-control device 120F,information indicative of a current number of passengers or users130A-130C in the ridesharing vehicles. Ridesharing management server 150may then determine whether to assign additional users to the ridesharingvehicles based on the received information from the sensor and capacitythresholds associated with the ridesharing vehicles.

In some embodiments, ridesharing management server 150 may compare thesensor data associated with a ridesharing vehicle with a capacitythreshold of the ridesharing vehicle, and may determine whether a numberof actual passengers within the ridesharing vehicle exceeds a capacitythreshold of the ridesharing vehicle. If, based on at least the sensordata, the number of detected passengers exceeds the capacity thresholdof the ridesharing vehicle, ridesharing management server 150 mayreassign one or more subsequent passengers. In some embodiments, athreshold block that prevents assignment of the additional users to theridesharing vehicle when the ridesharing vehicle's current utilizedcapacity is above a threshold being less than the ridesharing vehicle'scapacity threshold may also be implemented.

In some embodiments, ridesharing management server 150 may determine adiscrepancy between an actual number of passengers entering aridesharing vehicle at a specific pick-up location and the number ofpassengers expected to enter the ridesharing vehicle at a specificpick-up location, and may inform ridesharing management server 150 ofthe discrepancy, thereby causing a change in the route of theridesharing vehicle.

As discussed above, user devices 120A-120C, driver devices 120D and120E, and/or driving-control device 120F may respectively be installedwith a user side ridesharing application, and a corresponding driverside ridesharing application. Mobile communications device 200 may beinstalled with a user side ridesharing application, and a correspondingdriver side ridesharing application, and/or other software to performone or disclosed embodiments described in the present disclosure, suchas on mobile communications devices 120A-120F. Mobile communicationsdevice 200 may retrieve GPS/navigation instructions 268 from memory 250and may facilitate GPS and navigation-related processes or routesassociated with drivers 130D and 130E in communication with ridesharingmanagement server 150. Ridesharing management server 150 may receive aride request from one or more users 130A-130C, may receive data fromsensors including a number of passengers currently located in orexpected to occupy a ridesharing vehicle, and may take an action, suchreassigning passengers or changing a vehicle route, based on acomparison between the actual number of passengers detected and thevehicle occupancy, as described in greater detail below.

In some embodiments, ridesharing management server 150 may transmitinformation to user device 120A-C, which may he, for example, asmartphone or tablet having a dedicated application installed therein. Agraphical user interface (GUI) including a plurality of user-adjustablefeature user side or driver side ridesharing application settings may beincluded on a display of mobile communications devices 120A-120C tovisibly output information to one or more users 130A-C and/or drivers130D and 130E in relation to anticipated or detected vehicle occupancy.

FIG. 27 illustrates an exemplary embodiment of a memory 2700 containingsoftware modules consistent with the present disclosure. In particular,as shown, memory 2700 may include a ride request module 2702, a routemodule 2704, a detection and assignment module 2706, a transmissionmodule 2708, a database access module 2710, and a database 2712. Modules2702, 2704, 2706, 2708, and 2710 may contain software instructions forexecution by at least one processing device (e.g., processor 310),included with automated ridesharing dispatch system 300. Ride requestmodule 2702, route module 2704, detection and assignment module 2706,transmission module 2708, database access module 2710, and database 2712may cooperate to perform multiple operations. For example, ride requestmodule 2702 may include a communications interface configured toelectronically receive ride requests from a plurality of users, mayaccess memory, and may process the received ride requests. Route module2704 may determine a route for the ridesharing vehicle. Detection andassignment module 2706 may receive information indicative of a currentnumber of passengers in the ridesharing vehicle, and may determinewhether to assign additional users to the ridesharing vehicle.Transmission module 2708 may send instructions to pick up and drop offusers based on an assignment front detection and assignment module 2706.Database access module 2710 may interact with database 2712 which maystore any information associated with the functions of modules2702-2708.

In some embodiments, memory 2700 may be included in, for example, memory320 storing programs 330 including, for example, server app(s) 332,operating system 334, and data 340, and a communications interface 360,discussed above. Alternatively or additionally memory 2700 may be storedin an external database 170 (which can also be internal to ridesharingmanagement server 150) or external storage communicatively coupled withridesharing management server 150 (not shown), such as one or moredatabase or memory accessible over network 140. Further, in otherembodiments, the components of memory 2700 may be distributed in morethan one server.

In some embodiments, ride request module 2702 may receive, via acommunications interface, ride requests from a plurality of users. Asdiscussed above, the communications interface e.g., communicationsinterface 360) may include a modem, Ethernet card, or any otherinterface configured to exchange data with a network, such as network140. Communications interface 360 may receive ride requests from aplurality of users 130A-C, and ride requests may include multiplepick-up and drop-off locations, and may be initiated from a user sideridesharing application on one or more user devices 120A-C.

In some embodiments, ride request module 2702 may also access memory 320to store a capacity threshold for each of a plurality of ridesharingvehicles. The capacity threshold may include a total available number ofseats present in a ridesharing vehicle. Alternatively, the capacitythreshold may include a total amount of volumetric space available toaccommodate a plurality of passengers in a ridesharing vehicle. In someembodiments, ride request module 2702 may process the ride requestsreceived from the communications interface and assign to a ridesharingvehicle the plurality of users for pick up at a plurality of differingpick-up locations and for delivery to a plurality of differing drop-offlocations. Ride request module 2702 may also receive softwareinstructions for clustering a plurality of users to a single ridesharingvehicle based on a common pick-up point or a common drop-off point. Datareceived from ridesharing management server 150 may include GPS dataindicating a location of a plurality of users, user devices 120A-Cincluding user identifier data, and vehicle-for hire data indicating aplurality of vehicle-for-hire available for ridesharing. Data receivedfrom ridesharing management server 150 may also include a storedthreshold capacity of each of a plurality of vehicles-for-hire.

In some embodiments, route module 2704 may determine, based on processedride requests from ride request module 2702, a route for the ridesharingvehicle. For example, route module 2704 may determine an optimal routefor a particular ride based on the number of differing pick-up locationsand differing drop-off locations, and based on map information andenvironmental conditions, including for example, traffic or congestion.Route module 2704 may also calculate potential routes and guide users toa pick-off or drop-off location based on the received and processed riderequests. Route module 2704 may also utilize GPS/navigation instructions268 to facilitate GPS and navigation-related processes and instructionsand plan an optimum route for a plurality of passengers occupying asingle ridesharing vehicle.

In some embodiments, detection and assignment module 2706 may receivefrom at least one sensor within the ridesharing vehicle, informationindicative of a current number of passengers in the ridesharing vehicle.For example, detection and assignment module 2706 may detect, based onreceived sensor information, a current number of passengers positionedin each of the ridesharing vehicles, and may determine whether a numberof identified passengers exceeds a stored threshold or capacity for aparticular vehicle. Detection and assignment module 2706 may alsodetermine whether to assign additional users to a particular ridesharingvehicle based on the received information from sensors and the capacitythreshold associated with the ridesharing vehicle. Detection andassignment module 2706 may also determine whether to assign existingpassengers to another ridesharing vehicle.

In some embodiments, detection and assignment module 2706 may detect adiscrepancy between an actual and an expected number of passengersentering a particular ridesharing vehicle. Detection and assignmentmodule 2706 may also calculate a difference and, based on thedifference, change a route based on route module 2704 instructions of aparticular vehicle so to allow for or prevent pick-up of additionalpassengers. For example, a route of a particular vehicle may be extendedto allow for pick-up of additional passengers when an actual number ofpassengers entering a vehicle detected by detection and assignmentmodule 2706 is less than an expected number. Conversely, a route of aparticular vehicle may be shortened to prevent pick-up of additionalpassengers when an actual number of passengers entering a vehicledetected by detection and assignment module 2706 exceeds an expectednumber. Other route variations and changes to allow for passengerdrop-off may also be contemplated.

In some embodiments, detection and assignment module 2706 may receiveinformation from a plurality of sensors to detect vehicle occupancy andentry of passengers into a ridesharing vehicle. For example, detectionand assignment module 2706 may receive from ridesharing managementserver 150 audio and image data, captured by, for example, an imagesensor or a microphone associated with a ridesharing vehicle. Image andaudio data may be used to determine an actual number of vehicleoccupants and may be configured to detect the current number ofpassengers in the ridesharing vehicle. In some embodiments, theridesharing vehicle may include one or more a plurality of sensors thatmay also include LIDAR, proximity sensors, seat pressure sensors,thermal sensors, and/or other sensors to collect information related tovehicle occupancy. Detection and assignment module 2706 may receivedetected information from each sensor placed internally or externally toa ridesharing vehicle and may determine vehicle occupancy based on anycombination of sensor information. Detection and assignment module 2706may then make a vehicle assignment corresponding to the detected vehicleoccupancy.

In some embodiments, transmission module 2708 may communicate, based onassignment instructions from detection and assignment module 2706, toridesharing management server 150 a message to pick up and drop offusers. For example, transmission module 2708 may communicate pick-up anddrop-off locations. In some examples, transmission module 2708 maycommunicate with ridesharing management server 150 to send a firstmessage to a user device 120A to cause an indication of a calculatedestimated pick-up time to appear on a display of user device 120A. Themessage may appear in different formats, for example, a text messageincluding the estimated pick-up time, an audio message, or an image.Transmission module 2708 may communicate confirmation messages andnotification and/or alerts based on detected changes vehicle assignmentso that users can be notified that they are assigned to a differentridesharing vehicle. Transmission module 2708 may also transmit selectedvehicle assignment and reassignment instructions for mobile devices120A-C in accordance with detection and assignment module 2706instructions.

In some embodiments, database access module 2710 may cooperate withdatabase 2712 to retrieve information. Database 2712 may be configuredto store any type of information of use to modules 2702-2710, dependingon implementation-specific considerations. For example, in embodimentsin which database access module 2710 is configured to provide arecommendation to add users, remove users (based on detection andassignment module 2706), and/or reroute a vehicle (based on route module2704 and) based on a detected discrepancy amongst a number of vehiclepassengers, database access module 2710 may retrieve prior-collectedvehicle or map information from database 2712 in order to reassignpassengers or change the route of a ridesharing vehicle (or requestre-assignment of at least one of the plurality of users scheduled to bepicked up by the ridesharing vehicle to a different ridesharingvehicle). The change in route may also include a change in pick-up ordrop-off location. Further, database 2712 may store metadata associatedwith pick-up or drop-offs (based on ride request module 2702). In someembodiments, database 2712 may store one or more images of the pluralityof captured images and/or receive sensor data from a plurality ofsensors.

Modules 2702-2710 may be implemented in software, hardware, firmware, amix of any of those, or the like. For example, if the modules areimplemented in software, they may be stored in a server or one or moreservers. However, in sonic embodiments, any one or more of modules2702-2710 and data associated with database 2712, may, for example, bestored in processor 310 and/or located on ridesharing management server150, which may include one or more processing devices. Processingdevices of ridesharing management server 150 may be configured toexecute the instructions of modules 2702-2710. In some embodiments,aspects of modules 2702-2710 may include software, hardware, or firmwareinstructions (or a combination thereof) executable by one or moreprocessors, alone or in various combinations with each other. Forexample, modules 2702-2710 may be configured to interact with each otherand/or other modules of ridesharing management server 150 and/or asystem 100 to perform functions consistent with disclosed embodiments.

FIG. 28A is a schematic illustration of an example of an interior of avehicle 2800 used for ridesharing purposes according to a disclosedembodiment. Vehicle 2800 may include a plurality of seats to accommodatemultiple vehicle passengers. One vehicle passenger may be the driver. Insome embodiments, vehicle 2800 may include an autonomous driving vehicle(e.g., autonomous vehicle 130F) without a driver and/or seat designatedfor a driver. The interior of a vehicle 2800 may include a plurality ofsensors 2082 and 2084 to detect a current vehicle occupancy level. Forexample, sensors 2802 and 2084 may include one or more imaging and/orproximity sensors. Interior of vehicle 2800 may also include specificsensors 2802 a-d corresponding to each of the plurality of seats. Forexample, sensors 2802 a-d may include pressure sensors or thermalsensors that are activated when a passenger sits down and occupies aseat. Other types of sensors are contemplated. As shown in FIG. 28A,vehicle 2800 is empty and does not include any passengers. Accordingly,sensors 2082, 2084, and 2802 a-d may communicate to server 150 a statethat no vehicle passengers are detected.

In some embodiments, the plurality of sensors 2802 a-d equipped witheach seat may include weight sensors, thermometers to measure bodytemperatures, or may include seat belt sensors. The seat belt sensors(not shown) may include sensors located on seat belt buckles providedfor each seat in the vehicle. The seat belt sensors may determinewhether a seat belt is fastened or unfastened to detect if a passengerseat is occupied. In some examples, cameras may be mounted on each seator each headrest, and heart pulse sensors, electric field sensors, orother biometric sensors may be positioned on each scat to determineindividual seat occupancy. Detection and assignment module 2706 mayaggregate information for each seat including signals of detection andnon-detection to calculate a number of ridesharing occupants.

FIG. 28B is a schematic illustration of an example of an interior of avehicle used for ridesharing purposes according to a disclosedembodiment. As shown in FIG. 28B, vehicle 2800 includes four passengers2812 a-d positioned in the interior of the vehicle and each occupying anindividual seat. Sensors 2802, 2084, and/or 2082 a-d may communicatedetection of each the four passengers 2812 a-d to ridesharing managementserver 150. Although the example shown includes four passenger seats inan autonomous vehicle, as discussed earlier, in some embodiments, adriver may instead occupy one of the seats. Further, any appropriatenumber of passenger seats (e.g.. 1, 2, 3, 4, 5, etc.) and/or seatconfigurations (e.g., additional or fewer seats and/or additional fewerrows of seats) are consistent with the disclosed embodiments.

In some embodiments, sensors 2802 and 2084 may be configured to bepositioned at the exterior of the vehicle in order to detect vehiclepassengers in the proximity of and entering vehicle 2800. Such adetection may inform ridesharing management server 150 of an anticipatednumber of vehicle passengers 2812 a-d that may enter vehicle 2800.Detection and assignment module 2706 may also determine an actual numberof users entering the ridesharing vehicle by communicating with mobiledevices of the users. A short-range transceiver configured to determinean actual number of users entering the ridesharing vehicle bycommunicating with mobile devices of the users may also be contemplated.Detection and assignment module 2706 may also compare the detection ofvehicle passengers 2812 a-d external and internal to the vehicle toidentify any discrepancies and change a route or vehicle 2800trajectory. Consistent with this disclosure, detection and assignmentmodule 2706 may aggregate information for each seat 2802 a-d includingsignals of detection and non-detection to calculate a number ofridesharing passengers 2812 a-d. As shown in FIG. 28B, each ofpassengers 2812 a-d may also have mobile devices. Detection of themobile devices corresponding to each of vehicle passengers 2812 a-d maybe contemplated as a means to detect vehicle 2800 occupancy. Forexample, the radio-frequency (RF) signals emitted by electricallypowered mobile radio-emitting devices such as smartphones phones orsimilar personal wearable communication devices may be detected by asensor included in vehicle 2800. In some embodiments, a sensor, such asan image sensor associated with a mobile communications device withinthe ridesharing vehicle, may be configured (e.g., via softwareinstructions including in a ride sharing application) to detect thecurrent number of passengers in the ridesharing vehicle and to transmitthe detected number to, for example, ridesharing management server 150.

In some embodiments, each passenger may not be directly positioned ineach seat. For example, in some cases, vehicle passengers may bestanding, sharing a seat, sitting on another's lap, or otherwise notconfined to a seat. In such examples, other means of detection arecontemplated. For example, a LIDAR system implemented either internal orexternal to vehicle 2800 may calculate distance and/or location data ofpassengers 2812 a-d to determine occupancy. LIDAR systems may include atransmitter and a receiver emitting light pulses internal to or throughwindows of vehicle 2800 to gather distance data for passengers 2812 a-dlocated internal to vehicle 2800. LIDAR wavelengths may includeinfrared, near-infrared, or ultraviolet wavelengths, and may includeperiodic or continuous pulses. In some embodiments, the LIDAR system mayemit light pulses that reflect on seats, headrests, a dashboard,steering wheel, and passengers. Captured distance information based onreflected light may indicate an existence of absence of passengersinside vehicle 2800 or external to vehicle 2800, and detection andassignment module 2706 may incorporate this detected information toidentify occupancy and make a passenger assignment.

In some embodiments, an occupant can be identified based a point cloudimage. For example, a LIDAR system may obtain a point cloud image, anddetection and assignment module 2706 may compare the point cloud imageto a default template including a silhouette of at least one passengerpositioned internal to a vehicle to determine whether the point cloudimage identifies a vehicle passenger.

If there is a match or a substantially close match between the templateand the point cloud image, then a passenger is determined to be insidevehicle 2800. Alternatively, if there is no match between a point cloudimage and a template, then no passenger is determined to be withinvehicle 2800.

In sonic embodiments, a three-dimensional image volume in conjunctionwith a volumetric threshold may be determined and computed to determinethe occupancy of vehicle 2800. For example, an average volume for eachof seats 2802 a-d and a corresponding volume for a typical vehiclepassenger 2812 a-d may be determined. When one or more volumes exceed apredetermined threshold, a plurality of vehicle passengers 2812 a-d maybe detected in vehicle 2800. When one or more volumes fall below apredetermined threshold or threshold blocks, one or more passengers 2812a-d may not be in vehicle 2800. Alternately, a series of volumetricranges may be contemplated and correspond to a particular number ofpassengers 2812 a-d. For example, a low volume range may only indicate asingle vehicle passenger 2812 a-d, whereas a high volume range mayinclude three or four vehicle passengers 2812 a-d.

In some embodiments, detection may be temporal in nature. For exampleoccupancy detection may begin when a driver begins or stops driving. Ifa detected vehicle speed is almost zero (e.g., vehicle 2800 isstationary), then a vehicle occupancy may not be detected. However, whena vehicle speed is detected at a value greater than zero (e.g., vehicle2800 is in motion), then a vehicle occupancy may be detected. Suchtemporal detection constraints may enable detection and assignmentmodule 2706 to eliminate false detection results when passengers aremoving in and out of vehicle before a ride starts.

FIG. 29A is a flowchart of an example of a method 2900 for automaticallydispatching ridesharing vehicles. Steps of method 2900 may be performedby one or more processors of server 150 and/or memory 320 and memorymodules 2700, which may receive data from one or more user devices andone or more sensors.

At step 2902, ride request module 2702 may electronically receive riderequests from a communications interface (e.g., communications interface360) from a plurality of users. Ride requests may indicate a pluralityof differing pick-up and drop-off locations from the plurality of users.The plurality of users may send ride requests from multiple user devices120A-C. Ride request module 2702 may include software instructions forreceiving data from ridesharing management server 150, and may includesoftware instructions for receiving ride requests from a user sideridesharing application installed on each of the multiple user devices120A-C. In some embodiments, ride request module 2702 may also accessmemory 320 to retrieve a stored capacity threshold for each of aplurality of ridesharing vehicles in response to electronicallyreceiving ride requests from the plurality of users.

At step 2904, ride request module 2702 may process the ride requestsreceived from the communications interface and assign to a singleridesharing vehicle the plurality of users for pick up at a plurality ofdiffering pick-up locations and for delivery to a plurality of differingdrop-off locations. Ride request module 2702 may also receive softwareinstructions for clustering a plurality of users to a single ridesharingvehicle based on a common pick-up point or a common drop-off point. Datareceived from ridesharing management server 150 may include GPS dataindicating a location of a plurality of users, user devices 120A-Cincluding user identifier data, and vehicle-for hire data indicating aplurality of vehicle-for-hire available for ridesharing. Data receivedfrom ridesharing management server 150 may also include a storedcapacity threshold for each of a plurality of ridesharing vehicles.

At step 2906, route module 2704 may determine, based on the processedride requests, an optimum route for the ridesharing vehicle. Asdiscussed above, route module 2704 may also calculate potential routesand guide users to a pick-off or drop-off location based on the receivedand processed ride requests. Route module 2704 may also useGPS/navigation instructions 268 to facilitate GPS and navigation-relatedprocesses and instructions and plan an optimum route for picking up anddropping off a plurality of passengers occupying a single ridesharingvehicle.

At step 2908, detection and assignment module 2706 may receive from atleast one sensor within the ridesharing vehicle, information indicativeof a current number of passengers in the ridesharing vehicle. Forexample, detection and assignment module 2706 may detect a currentnumber of passengers positioned in each of the ridesharing vehicles, andmay determine whether a number of identified users exceeds a storedthreshold or capacity for a particular vehicle. This information may bestored in database 2712. In some embodiments, this information may bebased on one or more sensors (e.g., sensors 2802 a-d, 2802, and 2804).As discussed earlier, the sensors may be proximity sensors, pressuresensors, thermal sensors, image sensors, audio sensors, LIDAR-basedsensors, or any other detection mechanism. Sensor data may betransmitted to server 150 and may be compared to occupancy data indatabase 2712.

At step 2910, detection and assignment module 2706 may determine whetherto assign additional users to the ridesharing vehicle. In someembodiments, detection and assignment module 2706 may compare the sensordata from the particular vehicle with the capacity threshold of theparticular vehicle and may determine whether to assign existingpassengers to another ridesharing vehicle based on this comparison. Forexample, if the detected number of passengers is the same as thecapacity threshold, as shown in FIG. 28B, then no additional users willbe assigned to the ridesharing vehicle. Conversely, if the detectednumber of passengers is less than the capacity threshold, thenadditional users may be assigned to the ridesharing vehicle.Transmission module 2708 may communicate that additional users may beassigned to a ridesharing vehicle.

FIG. 29B is a flowchart of an example of another method 2920 forautomatically dispatching ridesharing vehicles. Steps of method 2920 maybe performed by one or more processors of server 150 and/or memory 320and memory modules 2700, which may receive data from one or more userdevices and one or more sensors.

At step 2922, ride request module 2702 may store a capacity thresholdfor each of a plurality of ridesharing vehicles. As discussed earlier,the capacity threshold may include a total available number of seatspresent in a ridesharing vehicle, as shown in FIG. 28A. Alternatively,the capacity threshold may include a total amount of volumetric spaceavailable to accommodate a plurality of passengers in a ridesharingvehicle. For example, a capacity threshold may include 4 seats, such asseats 2802 a-d shown in FIG. 28A.

At step 2924, ride request module 2702 may receive ride requests from aplurality of users. As discussed earlier at step 2902, ride requestmodule 2702 may electronically receive ride requests from acommunications interface 360 from a plurality of users. Ride requestsmay indicate a plurality of differing pick-up and drop-off locationsfrom the plurality of users. Ride request module 2702 may includesoftware instructions for receiving data from ridesharing managementserver 150, and may include software instructions for receiving riderequests from a user side ridesharing application installed on each ofthe multiple user devices 120A-C. As shown in FIG. 28B, passengers 2812a-d may supply ride requests to ride request module 2702, and areoccupying vehicle 2800.

At step 2926, ride request module 2702 may process the ride requestsreceived from the communications interface and assign to a singleridesharing vehicle the plurality of users for pick up at a plurality ofdiffering pick-up locations and for delivery to a plurality of differingdrop-off locations, as discussed earlier in step 2904. As shown in FIG.28B, passengers 2812 a-d were assigned to share a single ridesharingvehicle 2800. Processed data received from ridesharing management server150 may include GPS data indicating a location of a plurality of users,user devices 120A-C including user identifier data, and vehicle-for hiredata indicating a plurality of vehicle-for-hire available forridesharing to enable ride request module 2702 to assign a ridesharingvehicle.

At step 2928, route module 2704 may determine, based on processed riderequests from ride request module 2702, an optimum route for theridesharing vehicle. As discussed earlier in step 2906, route module2704 may also use GPS/navigation instructions 268 to facilitate GPS andnavigation-related processes and instructions and plan an optimum routefor a plurality of passengers occupying a single ridesharing vehicle.

At step 2930, detection and assignment module 2706 may receiveinformation indicative of a current number of passengers in theridesharing vehicle. As discussed earlier in step 2908, detection andassignment module 2706 receive from at least one sensor within theridesharing vehicle, information indicative of a current number ofpassengers in the ridesharing vehicle. In some embodiments, the at leastone sensor may include LIDAR, proximity sensors, pressure sensors,thermal sensors, and/or other sensors to collect information related tovehicle occupancy.

At step 2932, detection and assignment module 2706 may compare sensordata from a particular vehicle with the capacity threshold data from theparticular vehicle. Detection and assignment module 2706 and ridesharingmanagement server 150 may compare the sensor data associated withridesharing vehicles operated by drivers 130D and 130E, anddriving-control device 120F with the capacity threshold of theridesharing vehicles. Sensor data may be transmitted to server 150 andmay be compared to occupancy data in database 2710.

At step 2934, detection and assignment module 2706 may determine whetheran actual number of users within the particular vehicle exceeds a numberof users assigned to the particular vehicle. Detection and assignmentmodule 2704 may detect a current number of passengers positioned in eachof the ridesharing vehicles, and may determine whether a number ofidentified users exceeds a stored threshold or capacity for a particularvehicle. This information may be stored in database 2710, and may beretrieved to formulate the comparison.

At step 2936, if the number of users within the particular vehicleexceeds the number of users assigned to the particular vehicle,detection assignment module 2706 may reassign one or more users toanother ridesharing vehicle. Detection assignment module 2706 maycommunicate with database access module 2710 to retrieve prior-collectedvehicle or map information from database 2712 in order to reassignpassengers or change the route of a ridesharing vehicle. Transmissionmodule 2708 may communicate the reassignment. For example, if thedetected number of passengers is exceeds the capacity threshold, whichis met as shown in FIG. 28B, then additional users will be assigned toanother ridesharing vehicle. Conversely, if the detected number ofpassengers does not exceed the capacity threshold, then additional usersmay not be assigned to another ridesharing vehicle.

FIG. 29C is a flowchart of an example of a method 2940 for changing aroute for an autonomous ridesharing vehicle. Steps of method 2940 may beperformed by one or more processors of server 150 and/or memory 320 andmemory modules 2700, which may receive data from one or more userdevices and one or more sensors.

At step 2942, ride request module 2702 may receive a desired routeaccording to instructions from route module 2704 and based on aplurality of pick-up locations and a plurality of drop-off locations fordelivering the users. The route may include a plurality of pick-uplocations for picking up users, a number of the users expected to enterthe ridesharing vehicle at each pick-up location, and a plurality ofdrop-off locations for delivering the users. As discussed earlier, routemodule 2704 may also determine, based on the received route from riderequest module 2702, an optimum route for the ridesharing vehicle.

At step 2944, detection and assignment module 2706 may determine adiscrepancy between an actual and expected number of passengers enteringa ridesharing vehicle. For example, detection and assignment module 2706may determine a discrepancy between an actual number of passengersentering the ridesharing vehicle at a specific pick-up location and thenumber of users expected to enter the ridesharing vehicle at thespecific pick-up location. Detection and assignment module 2704 may thencalculate a difference based on received sensor information from aplurality of sensors, discussed above. Different sensors may be utilizedto make the detection of an actual number of passengers entering aridesharing vehicle at different pick-up locations.

At step 2946, route module 2704 may change a route, based on thedetermined discrepancy, for the ridesharing vehicle. For example, routemodule 2704 may change a route so as to allow for or prevent pick-up ofadditional passengers. For example, a route of a particular vehicle maybe extended to allow for pick-up of additional passengers when an actualnumber of passengers entering a vehicle is less than an expected number.Conversely, a route of a particular vehicle may be shortened to preventpick-up of additional passengers when an actual number of passengersentering a vehicle exceeds an expected number. Other route variationsand changes to allow for passenger pick-up and drop-off may also becontemplated, and may be implemented in real-time based on dynamic usageof user side ridesharing applications implemented on user devices120A-C. Transmission module 2708 may communicate the change in route tovehicle passengers.

The foregoing description has been presented for purposes ofillustration. It is not exhaustive and is not limited to the preciseforms or embodiments disclosed. Modifications and adaptations will beapparent to those skilled in the art from consideration of thespecification and practice of the disclosed embodiments. Additionally,although aspects of the disclosed embodiments are described as beingstored in memory, one skilled in the art will appreciate that theseaspects can also be stored on other types of computer readable media,such as secondary storage devices, e.g., hard disks or CD ROM, or otherforms of RAM or ROM, USB media, DVD, Blu-ray, Ultra HD Blu-ray, or otheroptical drive media.

Computer programs based on the written description and disclosed methodsare within the skills of an experienced developer. The various programsor program modules can be created using any of the techniques known toone skilled in the art or can be designed in connection with existingsoftware. For example, program sections or program modules can bedesigned in or by means of .Net Framework, .Net Compact Framework (andrelated languages, such as Visual Basic, C, etc.), Java, C++,Objective-C, HTML, HTML/AJAX combinations, XML, or HTML with includedJava applets.

Moreover, while illustrative embodiments have been described herein, thescope of any and all embodiments having equivalent elements,modifications, omissions, combinations (e.g., of aspects across variousembodiments), adaptations and/or alterations as would be appreciated bythose skilled in the art based on the present disclosure. The examplesare to be construed as non-exclusive. Furthermore, the steps of thedisclosed methods may be modified in any manner, including by reorderingsteps and/or inserting or deleting steps. It is intended, therefore,that the specification and examples be considered as illustrative only.

1-71. (canceled)
 72. An automated ridesharing dispatch system,comprising memory configured to store historical data associated withpast demand for ridesharing vehicles in a geographical area; acommunications interface; at least one processor configured to accessthe memory and to: use the historical data to predict imminent demand ofridesharing requests including predicting general zones in thegeographical area associated with imminent demand; select a holding zonefor prepositioning empty ridesharing vehicles in order to expeditesatisfaction of the predicted imminent demand; and send, via thecommunications interface, to a mobile communications device in aspecific ridesharing vehicle, instructions directing the specificridesharing vehicle to the holding zone.
 73. The system of claim 72,wherein the specific ridesharing vehicle is directed to the holding zoneto maintain a presence in the holding zone despite other ridesharingdemand in the geographical area.
 74. The system of claim 72, wherein theat least one processor is further configured to access in the memoryhistorical data collected about pick-up locations, days, and times ofprior ride requests.
 75. The system of claim 74, wherein the at leastone processor is further configured to access in the memory historicaldata collected about weather conditions associated with the prior riderequests.
 76. The system of claim 72, wherein the at least one processoris further configured to select the holding zone from a plurality ofpre-identified holding zones stored in the memory, wherein the holdingzone includes at least one of a specific location and a neighborhood.77. The system of claim 72, wherein the at least one processor isfurther configured to select a holding zone for the specific ridesharingvehicle using real-time data.
 78. The system of claim 72, wherein the atleast one processor is further configured to select a holding zone forthe specific ridesharing vehicle using data about passenger-capacity ofthe specific ridesharing vehicle.
 79. The system of claim 72, whereinthe at least one processor is further configured to select a holdingzone for the specific ridesharing vehicle using data about a shift of adriver of the specific ridesharing vehicle.
 80. The system of claim 72,wherein the at least one processor is further configured to identify aplurality of holding zones and to direct a plurality of emptyridesharing vehicles to the plurality of holding zones.
 81. The systemof claim 72, wherein the at least one processor is further configured toidentify a plurality of holding zones and to direct, based on thepredicted general zones in the geographical area, a single emptyridesharing vehicle to a first holding zone and at least two emptyridesharing vehicles to a second holding zone.
 82. The system of claim72, wherein the at least one processor is further configured todetermine a drop-off location for a last passenger riding the specificridesharing vehicle based on the selected holding zone and desireddestination of the passenger.
 83. The system of claim 72, wherein the atleast one processor is further configured to receive a rideshare requestfrom a mobile communications device of a user in a vicinity of aselected holding zone, and to send a message to an empty ridesharevehicle in the selected holding zone to pick-up the user, includingrouting instructions to a pick-up location in a vicinity of the selectedholding zone.
 84. The system of claim 72, wherein the at least oneprocessor is further configured to receive a rideshare request from amobile communications device of a user in a vicinity of the specificridesharing vehicle driving toward the selected holding zone, and tosend a message to another rideshare vehicle farther away from the userto pick up the user.
 85. The system of claim 72, wherein the at leastone processor is further configured to receive a rideshare request, froma mobile communications device of a user in a vicinity of the specificridesharing vehicle driving toward the selected holding zone, and tosend a message to the specific ridesharing vehicle to pick up the userwhen the desired destination of the user is in proximity to the selectedholding zone.
 86. The system of claim 72, wherein at least some of theridesharing vehicles are electrically-powered vehicles, and the holdingzone includes a location where the ridesharing vehicle can charge whilewaiting for a user assignment.
 87. The system of claim 72, wherein atleast some of the ridesharing vehicles are manually-drivable ridesharingvehicles, and the holding zone includes a location where the ridesharingvehicles can park while waiting for a user assignment.
 88. The system ofclaim 72, wherein at least some of the ridesharing vehicles areautonomous, and the holding zone includes a route along which theautonomous vehicle is directed to drive while awaiting a pick-upassignment.
 89. A non-transitory computer-readable storage mediumstoring instructions that, when executed by at least one processor,cause the at least one processor to perform a method for managing afleet of ridesharing vehicles, the method comprising: storing historicaldata associated with past demand for ridesharing vehicles in ageographical area; using the historical data to predict imminent demandof ridesharing requests including predicting general zones in thegeographical area associated with imminent demand; selecting a holdingzone for prepositioning empty ridesharing vehicles in order to expeditesatisfaction of the predicted imminent demand; and sending to a mobilecommunications device in a specific ridesharing vehicle, instructionsdirecting the specific ridesharing vehicle to the holding zone.
 90. Thenon-transitory computer-readable storage medium according to claim 89,wherein the specific ridesharing vehicle is directed to the holding zoneto maintain a presence in the holding zone despite other ridesharingdemand in the geographical area.
 91. The non-transitorycomputer-readable storage medium according to claim 89, whereinselecting the holding zone includes making a selection from a list ofholding zone options stored in memory.
 92. The non-transitorycomputer-readable storage medium according to claim 89, wherein themethod further comprises: identifying a plurality of holding zones; anddirecting, based on the predicted general zones in the geographicalarea, a single empty ridesharing vehicle to a first holding zone and atleast two empty ridesharing vehicles to a second holding zone.
 93. Anautomated ridesharing dispatch system, comprising: memory configured tostore historical data associated with past demand for ridesharingvehicles in a geographical area; a communications interface configuredto receive location information from a plurality of communicationdevices associated with a plurality of ridesharing vehicles; at leastone processor configured to access the memory and to: assign, toridesharing vehicles already transporting users, additional users forsimultaneous transportation in the ridesharing vehicles; trackassignments of each specific ridesharing vehicle to identify that afirst ridesharing vehicle and a second ridesharing vehicle are about tobe without passengers and without future assignments; direct the firstridesharing vehicle to a first holding zone based on a current locationof the first vehicle and a predicted imminent demand proximate the firstholding zone; and direct the second ridesharing vehicle to a secondholding zone other than the first holding zone based on a currentlocation of the second vehicle and a predicted imminent demand proximateto the second holding zone.
 94. The system of claim 93, wherein at leastone processor is further configured to direct the second ridesharingvehicle to a second holding zone when the first holding zone is at fullcapacity. 95-184. (canceled)